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LIMITED WARRANTY 

Corvus warrants its hardware products against defects in materials and 
workmanship for a period of 180 days from the date of purchase from 
any authorized Corvus Systems dealer. If Corvus receives notice of 
such defects during the warranty period, Corvus will, at its option, 
either repair or replace the hardware products which prove to be 
defective. Repairs will be performed and defective parts replaced 
with either new or reconditioned parts. 

Corvus software and firmware products which are designed by Corvus for 
use with a hardware product, when properly installed on that hardware 
product, are warranted not to fail to execute their programming 
instructions due to defects in materials and workmanship for a period 
of 180 days. If Corvus receives notice of such defects during the 
warranty period, Corvus does not warrant that the operation of the 
software, firmware or hardware shall be uninterrupted or error free. 

Limited Warranty service may be obtained by delivering the product 
during the 180 day warranty period to Corvus Systems with proof of 
purchase date. YOU MUST CONTACT CORVUS CUSTOMER SERVICE TO OBTAIN A 
"RETURN AUTHORIZATION CODE" PRIOR TO RETURNING THE PRODUCT. THE RAC 
(RETURN AUTHORIZATION CODE) NUMBER ISSUED BY CORVUS CUSTOMER SERVICE 
MUST APPEAR ON THE EXTERIOR OF THE SHIPPING CONTAINER. ONLY ORIGINAL 
OR EQUIVALENT SHIPPING MATERIALS MUST BE USED. If this product is 
delivered by mail, you agree to insure the product or assume the risk 
of loss or damage in transit, to prepay shipping charges to the 
warranty service location and to use the original shipping container. 
Contact Corvus Systems or write to Corvus Customer Service, 2100 
Corvus Drive, San Jose, CA, 95124 prior to shipping equipment. 

ALL EXPRESS AND IMPLIED WARRANTIES FOR THIS PRODUCT, INCLUDING THE 
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, 
ARE LIMITED IN DURATION TO A PERIOD OF 180 DAYS FROM DATE OF PURCHASE, 
AND NO WARRANTIES, WHETHER EXPRESS OR IMPLIED, WILL APPLY AFTER THIS 
PERIOD. SOME STATES DO NOT ALLOW LIMITATIONS ON HOW LONG AN IMPLIED 
WARRANTY LASTS, SO THE ABOVE LIMITATIONS MAY NOT APPLY TO YOU. 

IF THIS PRODUCT IS NOT IN GOOD WORKING ORDER AS WARRANTED ABOVE, YOUR 
SOLE REMEDY SHALL BE REPAIR OR REPLACEMENT AS PROVIDED ABOVE. IN NO 
EVENT WILL CORVUS SYSTEMS BE LIABLE TO YOU FOR ANY DAMAGES, INCLUDING 
ANY LOST PROFITS, LOST SAVINGS OR OTHER INCIDENTAL OR CONSEQUENTIAL 
DAMAGES ARISING OUT OF THE USE OF OR INABILITY TO USE SUCH PRODUCT, 
EVEN IF CORVUS SYSTEMS OR AN AUTHORIZED CORVUS SYSTEMS DEALER HAS BEEN 
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR FOR ANY CLAIM BY ANY 
OTHER PARTY. 

SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR 
CONSEQUENTIAL DAMAGES FOR CONSUMER PRODUCTS, SO THE ABOVE LIMITATIONS 
OR EXCLUSIONS MAY NOT APPLY TO YOU. 

THIS WARRANTY GIVES YOU SPECIFIC LEGAL RIGHTS, AND YOU MAY ALSO HAVE 
OTHER RIGHTS WHICH MAY VARY FROM STATE TO STATE. 
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Scope 

This manual describes the Constellation software provided by 
Corvus. It covers the Constellation I/II data structures, 
Constellation drivers, booting and logon procedures, and the 
Constellation II management utilities. It also contains an 
appendix which covers the operating system specific details of 
each implementation supported by Corvus. 

Related documents 



Corvus Mass Storage Systems General Technical Information 
Part Number: 7100-05945-01 

Omninet General Technical Information 
Part Number: 7100 Ot»UiA-Ol 

You should also be familiar with the System Manager Guide for 
your particular system. 

Conventions 



Hexadecimal values are suffixed with an h. For example, FFh, 
02h. 

A block is always 512 bytes. 

Lsb means least significant byte or least significant bit, 
depending on context. Similarly, msb means most significant byte 
or most significant bit. 
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Data structures are explained by describing each field of the 
structure, as shown below: 

Field name i Off/Len | Type | Description 

Field name is the name commonly used, either in the code or in 
this manual, to refer to the piece of data being discussed. 
Field names, when used in this manual, appear in bold. 

Off is the offset of the start of this field, and len is the 
length of the field, off and len are always in bytes, unless 
otherwise specified; off is zero-based, unless otherwise 
specified. 

Type is the data type of the field. The meaning of each type is 
given in the table below: 

Type Meaning 

BYTE An unsigned 8-bit value. 

WORD An unsigned 16-bit value; msb, Isb format. 

FWRD An unsigned 16 -bit value; Isb, msb format; a byte- 
flipped word. 

ADR2 An unsigned 16-bit value; msb, Isb format. 

ADR3 An unsigned 24~bit value; msb.. Isb format. 

ADR4 An unsigned 32-bit value; msb.. Isb format. 

BSTR A string of 1 or more characters, padded on the 
right with blanks (2 Oh) . 

NSTR A string of 1 or more characters, padded on the 
right with NULs (OOh) . 

FLAG A BYTE with bits numbered 7..0; msb.. Isb format. 

ARRY An array of 1 or more BYTEs. 

Description is a one or two line description of the field. 
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Table entries are described in the following format: 

Entry | Byte | Content (Meaning) | Field name 

Entry is the offset of this entry, zero-based unless otherwise 
specified. 

Byte is the byte offset of this field, zero-based. 

Content is the actual content of this field, given either in 
ASCII or hexadecimal. 

(Meaning) gives further explanation of the content, if necessary. 

Field name is the name of this field, and refers back to the 
entry description. 
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Introduction 

Chapter 1: Introduction 

Constellation software is written specifically for the care and 
management of the Corvus hard disk system. The Constellation 
software system allows you to create and maintain a multi-user 
system consisting of one or more computers in conjunction with 
one or more Corvus mass storage devices. 

Constellation I software supports Rev B/H drives, MUX networks, 
and single disk server Omninet networks. Constellation II 
software supports these, as well as Omnidrives, Banks, and 
multiple disk server Omninet networks. 

Access to the network is managed through user accounts. An 
account consists of a name, password, and a list of volumes to 
which the user is given access. Users must **log-on" to the 
network in order to start accessing their volumes. Once a user 
has logged-on, most applications software written for single-user 
systems may be used with no modification. 

Constellation software differs from other networking software in 
two key respects: 

1) Constellation software requires a system manager, who is 
responsible for disk space allocation and assigning 
user names and volume access. 

2} Transparent volvime sharing is NOT supported. That is, 
Constellation software does not detect the case where two 
users attempt to write to the same volume at the same time. 
The application must explicitly coordinate such access. 

Constellation software is divided into two parts: management 
utilities and user utilities. Management utilities are operating 
system independent and are used to maintain the disk resident 
data structures that define the network configuration. User 
utilities are operating system dependent, and include a boot or 
logon program, a disk driver, a mount utility, and a spooler. 

Overview 

This manual discusses the following topics: 
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Data structures 

Several data structures are maintained on the disks comprising 
the network. These include the Network User Table, the System 
Boot Table, and the Drive User, Volume, and Access Tables. 

The data structures are described in Chapter 2. 

Disk Drivers 

For each supported operating system, code is provided to support 
the Corvus disk as a file-structured device under the host 
operating system. The operating systems supported are listed in 
Appendix B. 

A typical disk driver is described in Chapter 3. 

Boot and logon 

For each operating system, code is provided which installs the 
disk driver into the host operating system, and initializes the 
mount table for a given user. 

The boot and logon process is described in Chapter 4, with 
specific details for each operating system given in Appendix B. 

Utilities 

Constellation software also encompasses a set of user utilities 
and a set of management utilities which are used to access and 
maintain the data structures. User utilities must run under the 
host operating system, whereas management utilities may be run 
from any available computer. 

The utilities are described in Chapters 5 and 6. 

How to use this manual 

In this manual, each chapter discusses the functionality of the 
sxobject piece of software. For instance, the chapter on disk 
drivers covers the functions a disk driver must provide. The 
chapters are written for the ideal world, where space and time 
are not limitations. In reality, not all functions can be 
implemented for each operating system. Specific implementation 
details, showing some of the limitations that must be 
acknowledged, are given in Appendix B. 
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This manual should be useful to several kinds of readers: 

o Software developers - Appendix B gives specific 

implementation details about memory locations used and 
volume formats. Software developers who are having 
trouble getting their applications to run with the Corvus 
software installed may consult the appropriate section of 
Appendix B to see where conflicts might exist. 

Additionally, the implementation of Constellation 
software uses several of the features of Corvus mass 
storage systems, including semaphores, the boot protocol, 
and the Active User Table (These features are described 
in the Corvus Mass Storage System General Technical 
Information Manual) . You can refer to this manual for 
examples of how to use these features in your own 
applications, such as electronic mail or a network data 
base. 

o Implementing support for a new operating system - Chapters 

3, 4, and 5 describe the pieces of software which must be 
written: a disk driver, boot or logon code, and user 
utilities. You will need to refer to Chapter 2 for 
descriptions of data structures. 

o Implementing or modifying the management utilities - Chapter 
6 gives descriptions of the management utilities. You 
will need to refer to Chapter 2 for descriptions of data 
structures . 
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Constellation II data structures 
Chapter 2: Constellation II data structures 



This chapter describes the data structures used by 
Constellation II. 

Overview 

Each network, which consists of one or more disk servers, has a 
Network User Table. The Network User Table contains entries for 
all users of the network, and is stored at each disk server. 
Also stored at each disk server is the System Boot Table. The 
System Boot Table points to the location of the boot code for 
each computer type attached to the network. The user information 
and boot code is stored at all disk servers so that it can be 
obtained from any disk server on the network, as required by the 
cold boot procedure (see Chapter 4) . 

One or more disk drives is attached to each disk server. 
Information local to each disk drive is stored only on the 
particular drive. This information includes the following: 

o Drive Infonnation Block - drive name and password 
o Drive Volume Table - location of each volume 
o Volume Access Table - volume access information 
o Drive User Table, Drive Access Table - user access 
information 

Rather than reserve a large fixed area for the Constellation II 
tables, we chose instead to reserve 1 block, through which all of 
the other tables may be located. Block 8, the Drive Infonnation 
Block, is this reserved block. All other tables are located in a 
volume known as the Corvus volume. This volume is like any other 
volume: it has an entry in the Drive Volume Table, and it may be 
located anywhere on the drive. The only identifier of the Corvus 
volume is a pointer to it in the Drive Information Block. 

The Corvus volume is a UCSD-format volume (see Appendix B for 
details on UCSD volume format) . All of the tables in the Corvus 
volume are treated as data files, and each has an entry in the 
volume directory. 

Figures 2.1a and 2.1b show where the data structures are located 
on each of the disk(s) comprising a network. 
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Figure 2.1a; constellation II network layout 
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Figure 2.1b: Constellation II disk layout 
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Constellation II data structures 



Detailed table descriptions 

Each structure is described in detail in Figures 2.3 through 
2.10. You should probably skip to the next section, Table 
manipulation, on first reading. 

There are implicit links among the Constellation II tables; that 
is, for each entry in a particular table, a corresponding entry 
may occur in another table. Figure 2.2 shows these implicit 
links. Required links are indicated by a double arrow, and 
optional links are indicated by a single arrow. Field names 
appear in bold. 

For instance, the double arrow pointing at Drive User indicates 
that for each entry in Drive Access, there must be an entry in 
Drive User that has the same value in the Dserid field. In other 
words, if there is an entry in Drive Access with a Userid of 1, 
then there must be an entry in Drive User with a Userid of 1, and 
these two entries refer to the same user. 

As another example, the single arrow pointing from Drive Volume 
to Volume Access indicates that for each entry in Drive Volume, 
there may be an entry in Volume Access that has the same value in 
the Btartblk field. In other words, if there is an entry in 
Drive Volume with a Btartblk of 1024, then there may be an entry 
in Volume Access with a Btartblk of 1024 as well. If there is, 
then the two entries refer to the same volume. 



Network User «-User — > Drive User «-Userid — > Drive Access 



I 
User/Owner 

I 
I 

V 

Volume Access 



-Btartblk- 



•>> 



Voladdr/Startblk 

I 
I 

V V 

Drive Volume 



Figure 2.2: Implicit links among Constellation II tables 
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Drive information block (block 8) 



File name; 
Location: 



N/A 

Block 8 of each drive. 



Description: The Drive Information Block occupies a fixed 

location on each disk on a Corvus network. This is 
the table used to find everything else. 



Access: 



Format: 



All Corvus utilities accessing the Corvus volume 
make use of this table since the address of the 
Corvus volume is located here. Only SYSGEN and 
FIXIT modify the information contained here. 

1 entry of 512 bytes 



Field Name |Off/Len| Type | Description 

Drive 1 0/10 1 BSTR 1 Drive name (unencrypted) 


Drivepass | 10/8 | BSTR | Drive password (encrypted) 


Server | 18/10 | BSTR | Server name (unencrypted) 


Serverpass | 28/8 | BSTR | Server password (encrypted) 


Crvsaddr | 36/4 | ADR4 | Block address of Corvus volume 


Size 1 40/4 1 ADR4 | Size of Corvus volume, in blocks 


Bootaddr | 44/4 | ADR4 | Block address of System Boot table 
1 1 1 (SYSTEM. BOOT) 


UnusedO | 48/4 | ARRY 1 Reserved. 


Driveinit | 52/1 | BYTE | Drive initialized flag (see Notes) 
1 1 1 = not initialized 
1 1 11= initialized 


Unusedl | 53/1 | BYTE | Reserved. 


Driveno | 54/2 | WORD | Drive number (l to 7) 



Figure 2.3: Drive Information Block (block 8) 

(continued on next page) 
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Drive information block (block 8) 



Field Name |Off/Len| Type | Description 



Online 1 56/1 | BYTE | Drive online indicator (see Notes) 
1 1 1 " not online 
1 1 1 1 = online 


Unused2 I 57/1 | BYTE | Reserved. 


NUblks 1 58/2 1 WORD | NETWORK. USER table size, in blocks 


DVblks 1 60/2 1 WORD | DRIVE. VOLUME table size, in blocks 


DUblks 1 62/2 1 WORD | DRIVE. USER table size, in blocks 


DAblks 1 64/2 1 WORD | DRIVE. ACCESS table size, in blocks 


SBblks 1 66/2 1 WORD | SYSTEM. BOOT table size, in blocks 




NUaddr 1 70/4 | ADR4 | NETWORK. USER table block address 




DUaddr 1 78/4 | ADR4 1 DRIVE. USER table block address 




SBaddr | 86/4 | ADR4 | SYSTEM. BOOT table block address 




*Unused3 1 91/1 | BYTE 1 Reserved. 




*VAaddr | 94/4 | ADR4 | VOLUME . ACCESS table block address 





Figure 2.3s Drive Information Block (block 8) 

(continued from previous page) 

Notes are located on the next page. 
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Drive information block (block 8) 

Notes: The fields driveinit, online, and special can be examined 
to determine whether a Drive Infoirmation Block is valid. 
I.e., if driveinit = 1 and online = 1 and special = 1982, 
then the Drive Information Block is probably valid. 

In Drive Information Blocks with Diversion of 0, the 
directory of the Corvus volume was written incorrectly; 
each file length was 1 block shorter than it should have 
been, indicating unused areas where data was actually 
located. This is not a problem unless the user "crunches" 
the Corvus volume. 

* These fields have been added for the Macintosh 
implementation . 
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Corvus volume 



File name: 
Location: 

Description! 



Access: 



Format : 



N/A 

A Corvus volume is located on each drive of the 
network, at the location indicated by the 
Crvsaddr field of the Drive Information Block. 

The Corvus volume contains the following tables, 
each embedded within the indicated file: 



*(1) 
(2) 
(3) 
(4) 
(5) 
*(6) 
*(7) 



Table 

System Boot Table 
Network User Table 
Drive Volvime Table 
Drive User Table 
Drive Access Table 
boot files 
Volume Access Table 



File name 

SYSTEM. BOOT 
NETWORK. USER 
DRIVE. VOLUME 
DRIVE. USER 
DRIVE. ACCESS 
BOOT . XXX 
VOLUME. ACCESS 



*These tables are optional. 

The Corvus volume is a standard UCSD format 
volume. Volume size may range from 64 to 600 
blocks. 

Only Constellation II utilities modify the data 
within the Corvus volume. The tables are normally 
found via the directory, although some utilities 
use the addresses found in block 8 instead. 

Offset and length are in blocks. 



Field Name |Off/Len| Type | Description 
I 0/2 I - I Unused. 



I 2/4 I - I UCSD format directory (see Appendix B) 
I 6/2 I - I SYSTEM. BOOT file 



8/ 
end 



I Other files, always in the following 

I order: NETWORK. USER, DRIVE . VOLUME , 

I DRIVE. USER, DRIVE. ACCESS, then zero 

I or more BOOT.xxx files. 



Figure 2.4a: Corvus Volume 
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Corvus volume 



File name EOF 

SYSTEM. BOOT 512 

NETWORK. USER 512 

DRIVE. VOLUME 512 

DRIVE. USER 512 

DRIVE. ACCESS 512 

BOOT. IBM 512 
<. . .> 



Date 

1 Sep 84 
Sep 84 
Sep 84 
Sep 84 
Sep 84 
Sep 84 



Off: Len 
6: 2 



8: 

40: 

72: 

104: 

202: 

212: 



32 

32 
32 
98 
10 
88 



Type 
data 
data 
data 
data 
data 
data 



Notes: 



Figure 2.4bi Example Corvus volume directory 

Although the Corvus volume is a standard UCSD volume, and 
It can be mounted under either the p-system or CCOS 
operating systems, you should never crunch the Corvus 
volume. If you do crunch the Corvus volume, you will 
invalidate the addresses in the Drive Information Block, 
and any utilities, including the boot code, which use 
these addresses will no longer work correctly, if you do 
inadvertently crunch the Corvus volume, you can try to 
recover by executing the management utility FIXIT 
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System Boot Table 



File name: 
Location: 

Description! 



Access: 



Format : 



SYSTEM. BOOT 

Corvus Volume. The contents of the System Boot 
Table should be the same on each drive on the 
network. 

The System Boot Table is always the first file of 
the Corvus volume. It is used by the Corvus Read 
Boot Block command described in the Corvus Mass 
Storage System GTI . Each entry in the table is 
the relative block address of the start of the boot 
code file for a particular computer. 

The table is manipulated by the Corvus BOOT 
MANAGER utility. 

2 bytes per entry; space for 256 entries. Unused 
entries contain FFh, FFh. Entries are ordered by 
boot code number (see Table A. 4). 



Field Name |Off/Lenl Type 
I 0/2 I WORD 



Description 

Block offset to start of boot file, 
relative to start of Corvus volume. 



Figure 2.5: System Boot Table 

Notes: The SYSTEM. BOOT file is always allocated 2 blocks; the 
second block is not used. 
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System Boot Table 



Entry | Byte | Contents 

+ + _ ^ 

I FFh I 

< < 

> > 

17 I FFh I 

— + . + 

9 18 I OOh I 

19 I CAh I 

— + . „ + 

10 20 I FFh I 

< < 

> > 

511 I FFh I 

— + . 



Figure 2.5b: Example System Boot Table 

Notes: In the example above, there is one entry in the System 
Boot table, entry number 9. Entry number 9 is assigned 
to the IBM PC (see Table A. 4 for computer number 
assignments) . The entry for the IBM PC, OOCAh, is equal 
to 202 (decimal) , and indicates that the boot code file 
for the IBM PC starts at block 202 of the Corvus volume. 
If everything is valid, then the Corvus volume should 
have a directory entry for the file BOOT.IBMPC with a 
starting block address of 2 02. 
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Network User Table 



File name: NETWORK. USER 

Location: Corvus volume. The contents of the Network User 
Table should be the same on each drive on the 
network . 

Description: The Network User Table identifies each user of the 
network. Each valid user of the network must have 
an entry in the user table. 



Access: 



Format : 



Sort field: 



Entries are modified by the USER MANAGER utility. 

Table size ranges from 4 to 32 blocks (a maximum of 
511 users requires 32 blocks) . Each entry is 32 
bytes long, allowing 16 entries per block. The 
first 32 bytes of the first block are reserved. 
Unused entries contain all OOh; end of table is 
indicated by an entry containing all FFh; see next 
section. Table manipulation, for more information. 

User 



Field Name |Off/Len| Type | Description 

User 1 0/10 1 BSTR | User or device name (encrypted) 


Userpass | 10/8 | BSTR | User password (encrypted) 


Server | 18/10 | BSTR | Home disk server name (encrypted) 


Opsys 1 28/2 1 WORD 1 Operating system type (see Notes) 


Hostkind 1 30/1 | BYTE | Type of user or device (see Notes) 


Hoststa 1 31/1 1 BYTE | Network address (devices only) 



Figure 2.6&: Network User Table 

Notes: Values for Opsys are positive integers; meanings are 
given in Table A. 3. Values for Hostkind are whole 
numbers; meanings are given in Table A.l; only generic 
meanings are used for this table. If Hostkind = 0, 
the entry is for a user, and Hoststa is ignored. 
If Hostkind <> and Hoststa <> 0, then the boot code 
will perform an automatic logon for this user; see 
Chapter 4, Special versions of boot code. 
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Network User Table 



Ent] 


ry 1 Byte | Contents 


(Meaning) 


■ 1 


Field name 





1 FFh 
< 
> 

31 1 FFh 






— — T" 

< 
> 

1 


Reserved 


1 


32-41 1 g..C.% 


.N}b 


(DENISE) 


■ — — T 
+ 


User 




42-49 1 yPI.t= 


cs 


(PITSCH) 




Userpass 




— — 1-— — 






+ 






50-59 1 ... i. 


.T.h 


(S) 




Server 




— +— 






+ 






60-61 1 OOlOh 




(CCOS) 




Opsys 




__+— . 






+ 






62 1 OOh 




(User) 




Hostkind 




_-+__ 






+ 






63 1 OOh 




(Unused) 


1 


Hoststa 


2 


^ a^-f. ■• M •» « -» B w> 

64-73 1 ... i. 


.T.h 


(S) 


■ — — ■?■ 
+ 


User 




74-81 1 .$Z.+. 


'P 


( ) 




Userpass 




-— +— — 






+ 






82-91 1 . . . .c. 


.N}b 


(S) 




Server 




1--.-. 






+ 






92-93 1 OOOOh 




(Unused) 




Opsys 




— — +— 






+ 






94 1 Olh 




(Disk) 




Hostkind 




__4.__ 






+ 






95 1 OOh 




(OOh) 


t 


Hoststa 




96 1 FFh 






■ — — + 


Unused 




< 






< 






> 






> 






511 1 FFh 

— + 






+ 





Figure 2.6b: Exeunple Network User Table 

Notes: In the entries above, User, Userpass, and Server are 
encrypted; the unencrypted values are given in 
parentheses . 
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Drive Volume Table 



File name: 



DRIVE. VOLUME 



Location: 



Corvus Volume 



Description: 



Access; 



Format; 



The Drive Volume Table contains an entry for each 
volume located on the drive. All operating system 
dependent information must be embedded in the 
volume itself. The Drive Volume Table contains an 
entry for the Corvus volume. 

All modifications to the Drive Volume Table are 
performed by the Corvus VOUJME MANAGER utility. 

4-64 blocks (maximum allows 511 volumes/ drive) ; 
32 bytes per entry; 16 entries per block; the 
first 32 bytes of the first block are reserved. 
Unused entries contain all OOh; end of table is 
indicated by an entry containing all FFh; see next 
section, Table manipulation, for more information. 



Sort field: 



Startblk 
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Drive Volume Table 



Field Name |Off/Len| Type | Description 

Volname | 0/10 | BSTR | Volume name (encrypted) 


Startblk | 10/4 | ADR4 | Address of first block of volume 


Endblk 1 14/4 | ADR4 | Address of last block of volume 


Voltype 1 18/1 1 BYTE | Directory type (see notes) 


1 1 1 « volxme is read only 
1 1 1 1 « volume is read/write 


1 1 1 = volume is not accessible 
1 1 1 1 = volume is accessible 




Reserved | 22/4 | NSTR | Reserved. 




ImgBlock | 28/4 | ADR4 | Image volume block number 



Figure 2.7a: Drive Volume Table 

Notes: Voloffset is normally 0, but can be used to reserve 

some blocks at the start of a volvime for additional volume 
information. When mounting a volume, the starting block 
address should be calculated as startblk + voloffset. 

Voltype is a value between 1 and 255 which indicates the 
volume directory type. Values are given in Table A. 2. 

ImgDate and ImgBlock are only significant if voltype is 
18 or 19, which means that this is an Image volume. 
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Drive Volume Table 



Entry | Byte | 

+ +- 

I 

< 
> 

31 I 
— +- 

1 32-41 I 

— +- 
42-45 I 

— +- 
46-49 I 

— +- 
50-53 I 

I 
— +- 

54-57 I 

— +- 

58-63 I 

— +- 

2 64-73 I 

— +. 

74-77 I 
— +- 

78-81 I 
— +- 

82-85 I 

I 
— +- 

86-89 I 

— +- 
90-95 I 
— +- 
96 I 
< 
> 
511 I 
— +■ 



Contents 
FFh 

FFh 

e. .X. ;.V. j 

OOOOOAOOh 

00000B2Bh 

Olh, Olh, 
Olh, OOh 

OOh, OOh, OOh, 

OOh 

e. . [ . . .V. j 

00000B2Ch 

00000B2Bh 

Olh, Olh, 
Olh, OOh 

OOh, OOh, OOh, 

OOh 

FFh 

FFh 



(Meaning) 



(CORVUS) I 

— + 

(1024) I 

— + 

(1223) I 
— + 

(UCSD, yes, I 
yes, 0) I 

— + 
OOh I 

— + 

(Unused) | 
+ 

(CCSYS) I 
— + 

(1224) I 
— + 

(....) I 

— + 

(UCSD, yes, I 

yes, 0) I 

— + 

OOh I 

— + 

(Unused) | 

+ 



Field name 
Reserved 

Vol name 

Startblk 

Endblk 

Voltype, Writeable, 
Glbaccess, Voloffset 

Reserved 

ImgDate, ImgBlock 

Volname 

Startblk 

Endblk 

Voltype, Writeable, 
Glbaccess, Voloffset 

Reserved 

ImgDate, ImgBlock 



< 
> 

I 
-+ 



Figure 2.7b: Example Drive vol\ime Table 
Notes: In the entries above, Volname is encrypted. 
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Drive user table 



File name: 

Location: 

Description! 



Access: 



Format: 



Sort field: 



DRIVE. USER 

Corvus Volume 

The Drive User Table is used to map user names to 
volumes accessible on a particular drive. Each 
user with access to a volume on the drive has an 
entry in the Drive User Table. The userid field of 
each entry corresponds to the userid field in the 
Drive Access Table. 

All table additions are made via the Corvus ACCESS 
MANAGER utility. Both the ACCESS MANAGER and the 
USER MANAGER utilities may delete entries. 

4-32 blocks (maximum of 511 entries requires 32 
blocks) ; 32 bytes per entry; 16 entries per block; 
first 32 bytes of the first block are reserved. 
Unused entries contain all OOh; end of table is 
indicated by an entry containing all FFh; see next 
section, Table manipulation, for more information. 

User 



Field Name |Off/Len| Type | Description 

User 1 0/10 1 BSTk | User name (encrypted) 


Userpass | 10/8 | BSTR | User password (encrypted) 


Userid | 18/2 | ADR2 | User number on this drive 


Mounted | 20/2 | ADR2 | Number of user volumes mounted 


Access 1 22/2 1 ADR2 | Number of user volumes accessible 


Bootinfo 1 24/2 1 ADR2 | User boot volume location flag 
1 1 1 «= not on this drive 
1 1 1 1 « on this drive 



Reserved | 26/6 



NSTR I Reserved. 



Figure 2.ea: Drive User Table 
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Drive user table 



Entry | Byte | Contents 

1 1 ... ■ 


(Meaning) 


1 Field name 

i__^_____a. — — — _ — 


1 FFh 
< 




1 Reserved 
< 


> 

31 1 FFh 

1 ... — — — 




> 
1 


1 32-41 1 g..C.%.N}b 


(DENISE) 


1 User 


__^.— _ 




— + 


42-49 1 yPi.t=cs 


(PITSCH) 


1 Userpass 


.— +— — 




— + 


50-51 1 0002h 


(2) 


1 Userid 


_— 4.— _ 




— + 


52-55 1 0002h, OOOEh 


(2, 14) 


1 Mounted, Access 


_— +— — 




— + 


56-57 1 OOOlh 


(yes) 


1 Bootinfo 


_.+— 




— + 


58-63 1 OOh 

1 


(Unused) 


1 Reserved 


2 64-73 1 ...Ri..T.h 


(SMGR) 


1 User 


)._— 




— + 


74-81 1 ilu./.dt 


(HAD 


1 Userpass 


__^ — _ 




— + 


82-83 1 OOOlh 


(1) 


1 Userid 


__4.— — 




— + 


84-87 1 0003h, 0005h 


(3, 5) 


1 Mounted, Access 


— +— — 




— + 


88-89 1 OOOlh 


(yes) 


1 Bootinfo 


__4.— — 




— + 


90-95 1 OOh 


(Unused) 


1 Reserved 


3 96 1 FFh 
< 




1 Unused 
< 


> 

511 1 FFh 

— + 




> 

1 
+ 



Figure 2.8b: Example Drive User Table 
Notes: In the entries above. User and Userpass are encrypted. 
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Drive Access Table 



File name: DRIVE. ACCESS 

Location: Corvus Volume 

Description: The Drive Access Table identifies each volume on 

the drive to which the user has access. Each entry 
contains the userid of a user identified in the 
Drive User Table, the physical volvime location, and 
user access information. The mount information 
mntinfo indicates which drive specifier a volume is 
associated with on boot. 

Access: The Drive Access Table is modified by the Corvus 

ACCESS MANAGER. The USER MANAGER, VOLUME MANAGER, 
and ACCESS MANAGER may delete entries. 

Format: 4-256 blocks (512 users, with access to 256 
volumes each, on a single drive requires 256 
blocks) ; 8 bytes per entry; 64 entries per block; 
first 32 bytes of first block are reserved. 
Unused entries contain all OOh; end of table is 
indicated by an entry containing all FFh; see next 
section, Table manipulation, for more information. 

Sort field: Userid concatenated with voladdr 



Field Name |Off/Lenl Type 
Userid | 0/2 | ADR2 



Description 

User nxomber on this drive 



Voladdr 
Mntinfo 



I 



2/4 I ADR4 
6/1 I BYTE 
7/1 I BYTE 



Starting block of volume 



OS dependent mount information 



Readonly/ 
Bootflag 



Readonly flag - bits 7-4 

= volume is read-write 

1 = volxime is read-only 
Boot volume flag - bits 3-0 

■ not user's boot volume 

1 = is user's boot volume 



Figure 2.9a: Drive Access Table 
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Drive Access Table 



Entry I Byte| Contents (Meaning) | Field name 

+ + . + 

I FFh I Reserved 

< < 

> > 

31 I FFh I 

— + + 

4 32-33 I OOOlh (User 1) | Userid 

34-37 I OOOOOAOOh (1032) | Voladdr 

38-39 I xxxxh (..) I Mntinfo, Readonly, 
I I Boot flag 

— + + 

5 40-41 I OOOlh (User 1) I Userid 

42-45 I OOOOOAOOh (1032) | Voladdr 

46-47 I xxxxh (..) I Mntinfo, Readonly, 
I I Bootflag 

— + + 

6 48-49 I 0002h (User 2) | Userid 

50-53 I OOOOOAOOh (1032) | Voladdr 

54-55 I xxxxh (..) I Mntinfo, Readonly, 
I I Bootflag 

— + + 

56 I FFh I Unused 

< < 

> > 

511 I FFh I 

— + + 



Figure 2.9b: Example Drive Access Table 

Notes: In the example above, user 1 has access to 2 volumes: 
the volume starting at block 1032, and the volume 
starting at' block 2048. To find the name of the volume 
starting at block 1032, you must search the Drive Volume 
Table for the entry that has a value of 1032 in the field 
startblk. To find the name of user 1, you must search 
the Drive User Table for the entry that has a value of 1 
in the field userid. 
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Drive Access Table 



File name: 

Location: 

Description: 



Access: 



Format: 



Sort field! 



VOLUME. ACCESS 

Corvus Volxime 

The Volume Access Table contains an entry for each 
volume located on the drive, giving access 
information for the volume. 

All modifications to the Volume Access Table are 
performed by the Corvus VOLUME MANAGER utility. 

4-64 blocks (maximxim allows 511 volumes/drive) ; 
32 bytes per entry; 16 entries per block; the 
first 32 bytes of the first block are reserved. 
Unused entries contain all OOh; end of table is 
indicated by an entry containing all FFh; see next 
section, Table manipulation, for more information. 

Startblk 



Field Name 
startblk 


Of f /Len 1 

Bsssssssassc 

0/4 1 


Type 

BE&rBBsasasB 

ADR4 


Description 

Address of first block of volume 


Owner 


4/10 1 


BSTR 


Name of user with R/W access 
(encrypted) 


Volpsw 


14/8 1 


BSTR 


Volume password (encrypted) 


AccType 


22/2 1 


WORD 


Access type 

- uncontrolled; 2 = public; 

1 ■ controlled; 3 = private 


Case AccTyp 
Lock 


24/8 1 
24/1 1 


ARRY 

BYTE 


Access information 
If AccType = 1 (controlled) , then 
= Volume is not locked 
1 1 = Volvime is currently locked 



Figure 2.10a: Volume Access Table 
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Drive Access Table 



Notes: Acctype specifies the type of access allowed for this 
volume. If no entry exists for a volume in the Volume 
Access table, or if no Volvime Access table exists, then 
the volume is mounted using information from the Drive 
Access table. 

The mount algorithm for each type of access is given 
below. The field Writeable is from the corresponding 
entry in the Drive Volxime table, and denotes either RO 
(writeable=0) or RW (writeable^l) ; the variable Username 
is the user name the user is logged in under. The 
parameter on the call to Mountit is either RO (read-only) 
or RW (read -write) . 

{ start of mount algorithm } 

Psw2Str( volpsw, pswd ) ; { decrypt volume password ) 

NeedPswd := LENGTH (Pswd>0) ; { does volume have a password? } 

IF NeedPswd THEN GetPswd(pass) ; { prompt user for volume password } 

CASE Acctype OF 

Uncontrolled: IF ((NeedPswd) AND (Pswd=pass) ) OR (not NeedPswd) 

THEN Mountit (Writeable) 

Controlled: IF ((NeedPswd) AND (Pswd=pass) ) OR (not NeedPswd) 

THEN Mountit (RO) 

Public: IF ((NeedPswd) AND (Pswd«pass) ) OR (not NeedPswd) 
THEN BEGIN 

IF Username = Owner THEN Mountit (Writeable) 

ELSE Mountit (RO) 
END; 



END; 



Private: IF Username = Owner THEN Mountit (Writeable) 
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Drive Access Table 

Entry I Byte| Contents (Meaning) | Field name 

+ + • + 

I FFh I Reserved 

< < 

> > 

31 I FFh I 

— + + 

1 32-35 I OOOOOAOOh (1024) | Startblk 
36-45 I (SMGR) | Owner 

46-53 I (XYZ) I Volpsw 

— + — — + 

54-55 I OOOOh (Uncontrol) | Acctype 

56-63 I OOh (Unused) | Filler 

— + + 

2 64-67 I 00000B2Ch (1224) | Startblk 

68-77 I (SMGR) | Owner 

78-85 I (ZZZZ) I Volpsw 

86-87 I OOOlh ( Control le) | Acctype 

88-95 I OOh (Varies) | Lock 

— + + 

96 I FFh I 

< < 

> > 

511 I FFh I 

— + + 



Figure 2.10b: Example Volume Access Table 
Notes: In the entries above, Owner and Volpsw are encrypted. 
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Table manipulation 



Table nanipulation 



A conunon set of routines is used to manipulate those tables which 
have a defined sort field. Each such table consists of one or 
more table blocks, where each table block is 2 disk blocks or 
1024 bytes. Each table block contains an integral number of 
entries; the entry size for each table was given in the previous 
figures. 

Within a table block, some entries are used, and some are empty. 
All used entries are grouped together at the beginning of the 
block, and all empty entries are always grouped together at the 
end of the block. Empty entries contain either OOh or FFh in all 
bytes of the entry. An entry containing OOh indicates that an 
entry has been deleted; an entry containing FFh indicates that 
the entry has never been used. The illustration on the next page 
will help you picture the table organization. 

This concept of empty entries within a block was used to keep 
insertion and deletion times down, the idea being that table 
blocks would tend to have one or more empty entries. 
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Table manipulation 



1st table block: 

The first 32 bytes of 
the first table block 
contain FFh, and 
should be ignored. 

Once you see an entry 
containing all OOh's, 
you can skip to the 
next table block. 



Used table block: 

An empty entry always 
indicates that a 
deletion has occurred, 

A table block may 
contain all OOh's, if 
many deletions have 
occurred . 



Table block with never-used 
entries: 

Once you see a table 
block with an entry 
of FFh, all succeeding 
table blocks should 
contain only FFh. 



+■ 

I 
< 



(1st 32 bytes reserved) 
Used entries 



> 

I 
+■ 

+■ 



Empty entries 
(all OOh) 



Used entries 



> 

I 

+■ 

I 

< 
> 



■+ 

I 
< 



> > 

I I 

+ + 

I i 

< Empty entries < 

> (all OOh) > 

I I 

+ . + 

+ , + 

I I 

< Used entries < 

> > 

I I 

+ . + 

I I 

< < 



Never-used entries 
(all FFh) 



> 

I 
■+ 

-+ 

I 
< 



> 

I 

-+ 

I 

< 
> 
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Table manipulation 

Four operations are allowed these tables: search, insert, 
delete, and replace. The routines used by the Constellation II 
management utilities to manipulate these tables are described in 
Chapter 6. The algorithms used for these operations are 
described here in order to give you a better feel for how the 
tables are organized. 

Each table has a defined sort field. Table entries are ordered 
alphabetically by this sort field. The search algorithm allows 
you to specify which field to base the search on; the search 
field may or may not be the sort field. If the search field is 
the sort field, the search stops when an entry greater than the 
entry being searched for is found. Otherwise, the search stops 
when a never-used entry is found. 

The search and insert algorithms are described in detail by 
Figures 2.10a and 2.10b. 

Table deletion is handled by finding the desired entry and moving 
all following entries in the table block back one entry. The 
last bytes in the table block are overwritten with OOh or FFh, 
indicating an empty entry. FFh is used only if other never-used 
entries are in this block. 

Replacement is handled by finding the old entry and overwriting 
it with the new entry. 
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Table manipulation 



Start 



Read next table 
block. 



Y 



Set Entries <- 
nximber of used 
entries in table 
block (may be 0) 

Set Cnt <- 




* Test only done if search field is the sort field. 



Figure 2.10a: Table search algorithm 
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Table manipulation 



(^^St&Tt~ ^ 



Use search 
algorithm to 
find spot 
vhere entry 
will go. 




Place item at 
first empty 
entry in pre- 
ceding block. 



Move appropriate 
entries forward 
one entry and 
insert item. 



Hove appropriate 1 
entries back one }-^(B) 
^1 entry and insert 



Move appropriate _^ 
entries forward -^(bj 
one entry and 



Unable to 
insert item, 
no room. 





Figure 2.10b: Table insertion algorithm 
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Table manipulation 



The insertion algorithm for inserting into a full table block is 
shown below. In each case, the new entry is to be inserted into 
block n+2, which is full. 

Case 1: a preceding block has empty entries 



Block n 

+ + 



Block n+1 

+ + 



Block n+2 

+ + 




Block n+3 

+ + 

I 

I 

I 
+ 



I 

+ 

I empty | 
I I 
I I 

+ 4 



Case 2: All preceding blocks are full, but a following block 
has empty entries. 



Block n 

+ + 



Block n+1 
+ + 



Block n+2 

+ + 
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Encryption 



Encryption 



All names and passwords in the tables are encrypted. Encrypting 
the names makes it harder for a malicious user to locate the 
Constellation II tables. Even if a user does locate the tables, 
figuring out how to decrypt the information is not easy, since 
each byte is encrypted based on its location within a name. 
Additionally, a different algorithm is used for encrypting names 
than is used for encrypting passwords. 

The name encryption algorithm preserves alphabetic ordering, so 
that a list of encrypted names and a list of the corresponding 
unencrypted names will sort in the same order. 

A set of procedures which performs encryption and decryption is 
described in Chapter 6. 

Active User Table 

The Active User table contains a list of those users and servers 
currently active on, or "logged-on" to, the network. Thus, it is 
a dynamic table which can be used to determine the current state 
of the network. As stated in the Corvns Mass Storage Systems 
GTI however, the Active User Table is not always up-to-date. 
The Active User table provides a rudimentary name service, and is 
intended for use by those applications which cannot utilize the 
Constellation name protocol. 
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Active User Table 



File name: 

Location: 

Description: 



Access: 



Format; 



N/A 

In firmware area 

The Active User Table contains entries for all 
users or servers currently active on the network. 
Each new user of the network is added to the table 
during cold boot or via the server logon protocol. 
An Active User Table entry consists of the user or 
server name, and the host address of the user or 
server. This table can be read by utility programs 
to find the addresses of various users or servers 
on the network. 

This table is initialized by the disk server. It 
is modified by the firmware in response to commands 
from a user logon or server power-up. 

4 blocks (maximum 128 entries - there are more 
than 64 to allow for multiple users per host) 
16 bytes per entry; 32 entries per block 



Field Name 
Host 


Off/Len 
0/10 


Type 
BSTR 


Description 

User or device name 


Hostno 


10/1 


BYTE 


Network address 


Hostkind 


11/1 


BYTE 


User or device type (see Table A.l) 


Reserved 


12/4 


BSTR 


Reserved 



Figure 2.12a: Active User Table 
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Active User Table 



Entry I Byte| Contents (Meaning) | Field name 

+ + + 

0-9 1 SERVERl I Host 

10 I Olh (1) I Hostno 

— + — — + 

11 I OOh (disk) I Hostkind 

12-15 I OOh (Unused) | Reserved 

— + _ + 

1 16 I 2 Oh I Unused 

< < 

> > 

31 I 20h I 

— + + 

2 32-41 I DENISE I Host 

42 I 13h (19) I Hostno 

43 I 2 Oh (Concept) | Hostkind 

44-47 I OOh (Unused) | Reserved 

— + + 

48 I 2 Oh I Unused 

< < 

> > 

511 I I 

+ + 



Figure 2.l2bt Example Active User Table 



There is an Active User Table on each disk server on the network. 
See the Corvus Mass Storage Systems GTI , for descriptions of 
the commands which access the Active User table. 

The Active User Table can be updated by choosing the List 
Drives On-line option of the Constellation II management 
utilities. The algorithm used to update the Active User table is 
shown in Figure 2 . 13 . 
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X 



Read Active User table 
from a server 



(23 




Active User Table 



*Actname, ActAddr, and 
Actkind are the name, 
host address, and device 
type from the current 
Active User Table (AUT) 
entry. 

* * Curname , Cur Addr , and 
Curkind are the name, 
host address, and device 
type obtained by the 
Who Are You message. 



Set Actname*, ActAddr, 
Actkind from AUT entry. 



>l' 



Send Echo command to ActAddr. 




Broadcast Goodbye >. 
message for Actname. J 



Send Who are you message. 
Set Curname**, CurAddr, 
Curkind from response, 




Broadcast Goodbye 
■^message for Actname. 



1 Broadcast Hello 

1 ^ me ssage for Curname. 




Cnt<-Cnt+1 



.Cnt>127>--7(B 





Figure 2.13: Flowchart of update Active User Table 
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Constellation disk drivers 



Chapter 3: Constellation Disk drivers 



A simple disk driver was described in Chapter 3 of the Corvus 
Mass Storage Systems GTI. You will have to refer to that 
chapter for complete information on writing a disk driver; this 
chapter discusses only the particular functions of a 
Constellation disk driver. 

Figure 3.1 summarizes the disk driver functions required of a 
Constellation disk driver. These functions are the ideal set 
that a driver should provide. In reality, it is not always 
possible to provide all of these functions, due to limftations of 
the operating system interface, or space limitations. The actual 
functions provided by the drivers supplied by Corvus are 
described in Appendix B. 



Function 

Driver initialization 
Device read 
Device write 



How used 

Standard BIOS call 



Send Corvus drive command 
Send Omninet command 



Utilities, user 
applications 



Mount 

Unmount 

Get mount information 



Mount utility, user 
applications 



Figure 3.1: Disk driver functions 



A Constellation disk driver maintains a structure known as the 
mount table. The mount table serves as a map between an 
operating system device number and a volume on a Corvus drive. 
The driver will normally support a fixed sized mount table, 
supporting between 6 and 10 mount table entries. We have found 
through experience that while 2 or 3 disk devices are sufficient 
for most applications, there are occasions where 6 are not 
enough. On the other hand, most drivers have limited data space, 
so you don't want to make the mount table too large. 
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Constellation disk drivers 



Each entry in the mount table must contain the following 
information: 



o 
o 
o 

o 
o 



Corvus disk server address - 1 byte 

Corvus disk drive number - 3 bits 

Corvus disk block address (starting block address of 

volume) - 3 or 4 bytes 

Corvus volume length, or ending address (2 or 3 bytes) 

Read-write flag - 1 bit 



Therefore, each device entry requires at least 7 bytes. In 
addition, the driver must store the user's name, and may also 
store the user's password, home disk server address, and 
transporter address. Figure 3.2 shows a typical mount table 
description. See Appendix B for the exact format of each 
operating system's mount table. 



VAR MT: RECORD 

Devices: ARRAY [1..10] OF RECORD 
Diskserver : BYTE ; 
Dr iveNo : BYTE ; 
StartBlk: 
VolLen: 



PACKED ARRAY [1..4] OF BYTE; 
INTEGER; 



Writeflag: BOOLEAN; 
END; 



User: 
Userpass: 
HomeDS : 
UserAddr: 
END; 



PACKED ARRAY [1..10] OF CHAR; 
PACKED ARRAY [1..8] OF CHAR; 
BYTE ; 
BYTE; 



Figure 3.2: Sample mount table declaration 
Each function listed in figure 3.1 is now discussed in detail. 

Driver initialization 

This call is a standard BIOS function in most operating systems. 
It is used to perform whatever initialization is required. In 
the case of a Constellation disk driver, this call can be used to 
initialize the mount table, if this has not been done previously 
(e.g., during boot). 
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Constellation disk drivers 

Device read, device write 

The usual parameters to device read or write include the 
following: 

Device number 
Sector number 
Number of sectors 
Data buffer 
Result code 

The driver must first of all check that the device number is 
valid, and that a mount table entry exists for this device 
number. If the device number is invalid, the driver should 
return a result code indicating "device not on-line". 

If the request is a device write, then the driver must validate 
that the write flag is set in this device's mount table entry. 
If not, the driver should return a result code indicating "write 
protected" . 

Next, the driver must validate that the sector number is valid, 
by comparing it to the volume length field in the mount table. 
If the sector number is out of range, the driver should return a 
result code indicating "invalid sector address". 

Next, the driver must build the appropriate read or write command 
to be sent to the Corvus disk. Refer to Chapter 3 of the Corvus 
Mass Storage Systems GTI for a thorough description of this 
step, which includes building a command vector, sending it to the 
proper disk, and receiving the results. Remember that the sector 
size is operating system dependent, and that the appropriate 
Corvus read or write sector command must be used. The sector 
number specified in the driver call must be converted to an 
absolute disk sector address by adding it to the starting block 
address from the mount table. The drive number and disk server 
address must also be obtained from the mount table. 

The read or write command must be repeated for the appropriate 
number of sectors, as specified in the driver call. 

Send Corvus drive command (CDSEND, CDRECV) 

The driver should provide an interface for sending arbitrary disk 
commands, such as pipes or semaphores commands. Refer to Chapter 
4 of the Corvus Mass Storage Systems GTI for a detailed 
description of this function. 
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Mount, unmount/ get mount Information 

The driver should also provide an entry point that allows for 
changing the mount table. This function can be used by 
applications which require certain volumes to be mounted, and by 
a user who has access to more volumes than the driver supports. 

In Corvus implementations, these functions are often provided by 
two low-level functions: Read mount table and Write mount table. 
As their names imply, these functions simply move the entire 
mount table between the driver's memory and a user-supplied 
buffer. Since these functions require a detailed knowledge of 
the structure of the mount table, it is desirable to provide a 
user library which implements the higher-level functions mount, 
unmount, and get mount information. These functions are 
described in Chapter 5, User Utilities. 

The Read Mount Table entry point has two parameters, both output 
parameters. The first parameter is an integer which contains the 
length of the mount table; the second parameter is a buffer which 
contains the mount table itself. The caller must ensure that the 
buffer is large enough to accomodate the mount table. 

The Write Mount Table entry point has one parameter, a buffer 
which contains the new mount table. 

Extreme caution must be used in calling these entry points, since 
writing incorrect information to the mount table could cause data 
on the Corvus drive to be overwritten. 

Send Omninet command 

The driver may also provide an interface for sending arbitrary 
Omninet messages, such as Send message or Setup Receive message. 
The details of this interface vary widely among implementations; 
you should look at the individual descriptions in Appendix B for 
information on this function. 

Ideally, the Omninet functions should be supported by a 
transporter driver, and the disk driver should call on the 
transporter driver when sending commands. In reality, however, 
only the Concept Operating System currently provides both a 
transporter driver and a disk driver. Since this manual is 
intended to describe the current state of Constellation II, it 
does not describe a separate transporter driver. Documentation 
on transporter drivers will be published by Corvus as soon as it 
is available. 

Although this manual does not describe a transporter driver, it 
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is important to realize that providing a separate transporter 
driver and disk driver is much superior to providing only a disk 
driver. With only a disk driver, certain sockets and data 
buffers of a buffered transporter must be reserved for exclusive 
use by the disk driver. Applications which desire to use the 
transporter directly must be coded so as not to interfere with 
the disk driver. If the disk driver changes at all, then such 
applications may no longer work properly. Having a transporter 
driver which controls access to sockets and buffers will resolve 
these potential conflicts. Therefore, it is recommended that all 
future development of disk drivers implement both a transporter 
driver and a disk driver. 
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Chapter 4: Boot and logon procedure 

This chapter describes the tasks of a typical boot from the 
Corvus drive. As mentioned for disk drivers, the set of tasks 
described here is the ideal; in reality, it is not always 
possible to provide all of these functions, due to limitations of 
the operating system interface, or space limitations. The actual 
functions provided by the various boot and logon programs 
supplied by Corvus are described in Appendix B. 

This chapter discusses both boot and logon, which are two 
separate functions. Boot refers to the process of loading and 
launching the operating system; logon refers to the process of 
validating a user's name and mounting the user's volumes. How 
boot and logon are accomplished is operating system dependent. 
In some cases logon is performed after the boot has been 
completed, and in other cases it is performed as part of the 
boot. 

There are several reasons why it is desireable to boot from the 
Corvus disk, rather than from some local device such as a floppy. 
First, one of the reasons for buying a network is to minimize 
hardware cost per user; if each user can boot from the Corvus 
disk, then each computer does not need to have a floppy drive 
attached. Second, it is usually faster to boot from a hard disk 
than it is to boot from a floppy disk. Thirdly, when a new 
version of the operating system is released, only the copy on the 
hard disk needs to be updated; with a floppy disk boot, each 
user's boot floppy needs to be updated. 

Despite the many advantages of booting from the Corvus disk, 
there are computers for which Corvus does not support booting. 
Some computers do not have the capability to boot from an 
external device. In other cases, the operating system supplier 
does not make available the information which Corvus must have in 
order to develop boot code. 

Corvus boot protocol was established to allow many types of 
computers to boot from one disk. We didn't want to reserve disk 
sectors for each computer type, which would be wasteful of space 
since most networks have only one or two computer types 
connected. We also chose not to reserve a large fixed area. 
Instead, we chose to reserve one block (block 8) , to be used as 
an indirect pointer to where the boot code is located. A second 
indirect pointer indicates where, within the boot blocks, a 
particular computer's boot code is located. 

Each computer that is supported by Corvus is assigned a number 
which is its "boot" number. (See Figure 4.1 for boot number 
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assignments.) The boot number is used to indicate the location of 
that computer's boot code. The Read Boot Block command, a 
firmware command to the disk controller, is used to read the boot 
blocks. Thus, any computer can do a cold boot from the Corvus 
drive by issuing the Read Boot Block command to load its boot 
code and then using that code to bootstrap itself up. You should 
refer to the description of the Read Boot Block command given in 
the Corvus Mass Storage Systems GTI. 

The BOOT MANAGER program is provided to allow easy update of the 
boot blocks. The BOOT MANAGER maintains the boot blocks as files 
within the Corvus volume. For further information on BOOT 
MANAGER, see Chapter 6. 

Figure 4.2 shows a drive which is set up to boot 2 computer 
types: IBM PC and TI Pro. You may wish to refer back to the 
description of the System Boot table in Chapter 2 . 



boot number computer type 



boot file name 



0, 1, 2, 


, 3 


Apple II 


BOOT. APPLE 2 


4, 5, 6, 


r 7 


Concept 


BOOT. CONCEPT 




9 


IBM 


BOOT.IBMPC 




10 


Xerox 820 


BOOT.XR820 




11 


Zenith H89 


BOOT. HZ 8 9 




12 


NEC PCS 000 


BOOT.NC 




13 


Pet 


BOOT. PET 




14 


Atari 800 


BOOT.ATARI800 




15 


TRS-80 MOD I 


BOOT.TKSI 




16 


TRS-80 MOD III 


BOOT.TRSIII 




17 


LSI-11 


BOOT.LSIll 




18 


Printer server 


BOOT.PRINTSRV 




19 


Apple /// 


B00T.APPT,F3 




20 


DEC Rainbow 


BOOT. RAINBOW 




21 


TI Pro 


BOOT.TIPRO 




22 


Z-100 


BOOT. Z 100 




23 


Concept2 


B00T.C0NCEPT2 




24 


Companion 


BOOT. COMPANION 




25 


Macintosh 


BOOT. MAC 




26 


Sony SMC-7086 


BOOT. SONY 


Figure 


4.1 


: Boot Bunber assignments and fi 
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boo^ Cod£. Tor 



bocA teds fer- 
TXfro 



&0OT.Xr5r^aPc 5,^ 2i2: id 
Boot. TiPRo 5i^ z:i2'. ^ 



5i^&(ew\ 6fc4 T^i'^ 




a.ia 



^aa 






Figure 4.2: Boot tables for 2 computers 



The boot code is generally divided into two parts. The first 
part, referred to as the first stage boot, is generally resident 
in a boot ROM, and must perform the following steps: 

1) Locate a disk server. 

2) Load the second stage boot code. 

The second stage boot code is located in the boot file in the 
Corvus volxime. It must perform the remainder of the boot and 
logon procedures: 
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3) Load the rest of the boot code (if necessary) . 

4) Prompt for user name and password. Read the NETWORK. USER 
table and validate the user name and password. Obtain the 
home disk server name and operating system type from the 
user's entry in the NETWORK. USER table. 

5) Locate the user's home disk server. 

6) Update the Active User table with the user information. 

7) Locate the user's boot volume and load the operating 
system. 

8) Build the user's mount table. 

Once all this has been accomplished, the boot code jumps to the 
operating system, allowing it to complete the boot. 

It is also possible that a computer will boot from some local 
device, and logon to the network after booting. This logon does 
not need to load any boot code or operating system code (steps 2, 
3, and 7 above); however, it must perform all the other steps. 

Detailed description of boot process 

Each of the steps 1 through 8 listed above is now described in 
more detail. A text explanation is given, followed by a box 
containing pseudo-code that performs the task being discussed. 

The format of pseudo-code used is similar to that use^ in the 
Corvus Mass Storage Systems GTI in describing disk drivers. It 
is assumed that you are familiar with the Omninet command vectors 
and Omninet Protocols described in that manual. 

The declarations used by the pseudo-code are given on the next 
page. 
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Sample data structures 

First the data structure is declared, then a list of offsets 
into the structure are declared. 



Transporter command vector (see Omninet GTI , pgs. 32,33) 
It is not necessary to have more than one command record, 
although it is sometimes more convenient to use separate 
records which are preinitialized as Send and Setup receive 
commands . 



TCmd 


.BYTE 




.BYTE 




.WORD 




.BYTE 




.BYTE 




.WORD 




.WORD 




.BYTE 




.BYTE OFFh 


Opcode 


.EQU 


ResAdr 


.EQU 1 


Sock 


.EQU 4 


DatAdr 


.EQU 5 


DataLer 


I. EQU 8 


CrtlLer 


I. EQU 10 


Dest 


.EQU 11 


Destecho.EQU 4 


; Result record d 


SndRes 


.BYTE 




.BYTE 




.WORD 



RCode .EQU 



Rcv80 



Src 



.BYTE 
.BYTE 
.WORD 

.EQU 1 



Opcode - command code 

ResAdr - high order byte of result address 

- low order word of result address 
Sock - socket number 

DatAdr - high order byte of data address 

- low order word of data address 
DataLen - data length 

CrtlLen - user control length 

Dest - destination host number 

offsets 

offset to Opcode 

offset to ResAdr 

offset to socket number 

offset to DatAdr 

offset to data length 

offset to user control length 

offset to destination host number (Send only) 

offset to destination host number (Echo only) 



Send result record 

transporter return code 

unused 

unused 

offsets 

offset to transporter return code 

Receive result record 

transporter return code 

Src - source host number 

unused 

offsets 

offset to Src 
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Sample data structures (cont.) 
Data area buffers 



MsgBuf 





; Send buffer 


.WORD 


; ProtoID 


.WORD 


; MsgTyp 


.WORD 


; Source 


.WORD 


; DevType 


.WORD 


; Name (10 bytes) 


.WORD 




.WORD 




.WORD 




.WORD 





ProtoID. EQU 
MsgTyp .EQU 2 
Source .EQU 4 
DevType. EQU 6 
Name .EQU 8 



SSOMsg 



.WORD 

.WORD 

.WORD 

.WORD 

.WORD 

.WORD 

.WORD 

.WORD 

.WORD 



; local variables 
Timeout. WORD 
MyAddr .BYTE 
Bootsrv.BYTE 



offsets 

offset to ProtoID 
offset to MsgTyp 
offset to Source 
offset to DevType 
offset to Name 

Receive buffer 

ProtoID 

MsgTyp 

Source 

DevType 

Name (10 bytes) 



; used to control disk server wait loop 
; this computer's transporter address 
; transporter address of boot server 
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1. Locate a disk server: 



First, you should make sure that there are no other nodes 
with your address on the network. This is accomplished by 
issuing an Omninet Echo command to your address. If you 
get a response, then report an error. 

Send a WhoamI command to get your address: 

+ . + 

|TCmd+Opcode <- Olh (WhoamI command code) | 
JTCmd+ResAdr <- address of SndRes | 

I I 

I SndRes+Rcode <- FFh (initialize result code) | 

+ ■ ■ + 

Wait for result code to change. Store result in MyAddr: 

+— ■ ■ + 

I MyAddr <- SndRes+RCode | 

+ • + 

Send an Echo command: 

+ • ■ + 

|TCmd+Opcode <- 02h (Echo command code) | 
JTCmd+ResAdr <- address of SndRes | 

I TCmd+Destecho<- MyAddr j 

I I 

I SndRes+Rcode <- FFh (initialize result code) | 

+— ■ ■ + 

Check result: 

+ ■ + 

I If SndRes+RCode = COh THEN error. | 

+ ' + 

Once you have made sure that no other transporters with your 
address are present on the network, you can proceed to to 
look for a disk server. This procedure involves using the 
Name lookup protocol. The procedure is summarized below, and 
is shown in detail in the flowchart in figure 4.3. 

Broadcast 'Who are you, any disk server' command. If no 
response in 5 seconds, try again; retry 3 times. If still no 
response, broadcast illegal command (Old Disk server 
Protocol) . If no response in 5 seconds, try again; retry 3 
times. If still no response, report error. 
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Cstart ) 



JL 



] Count <- . / 

I - — ■ I 

-^ 



T 



Time <- Timeout. 



1l 



a. Setup receive 
for reply 



k. 



b. Broadcast message 




T Timedout 




(sj \ Re setup 
s> > receive 



Note: the lower case letters in some of the boxes refer to 
descriptions on the next pages. 

Figure 4.3: Flowchart of find a disX server 
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a. EndRecv on socket 8 Oh. 

+ 



I TCmd+Opcode <- lOh (EndRecv command code) 
JTCmd+ResAdr <- address of SndRes 
JTCmd+Sock <- 8 Oh 

I 

I SndRes+Rcode <- FFh (initialize result code) 

+ , 



Setuprecv on socket 8 Oh. The expected response is 
a 'My ID is' message. 

+ + 

I TCmd+Opcode <- FOh (Setuprecv) 

JTCmd+ResAdr <- address of Rcv80 

JTCmd+Sock <- 80h 

JTCmd+DatAdr <- SSOMsg 

I TCmd+DataLen <- 12h (18 bytes) 

I TCmd+CrtlLen <- 

I 

|Rcv80+Rcode <- FFh 

+ . 



b. Broadcast a 'Who are you' message 

+ 

TCmd+Opcode <- 4 Oh (Send) 

TCmd+ResAdr <- address of SndRes 

TCmd+Sock <- 80h 

TCmd+DatAdr <- address of MsgBuf 

TCmd+DataLen <- 08h (8 bytes) 

TCmd+CrtlLen <- 

TCmd+Dest <- FFh (Broadcast) 

SndRes+Rcode <- FFh 

MsgBuf +Pid <- OlFEh 

MsgBuf +MsgTyp <- 02 00h (Who are you) 

MsgBuf+Source <- MyAddr 

MsgBuf+DevType<- Olh (Generic disk server) 



c. Check for message received, when result code goes to 0. 

+ . + 

I IF Rcv80+Rcode=0 THEN check message ELSE increment time| 

+ , + 
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d. If Rcv80+Rcode is 0, then check that it is a My Id Is 
message that has been received. 

+ + 

I IF (S80Msg+Pid=01FEh) AND (S80Msg+MsgTyp-1000h) | 
I THEN Bootsrv <- saOMsg+Source | 

I ELSE ignore message j 

+ + 

If no disk server is found, then you must repeat the entire 
sequence, this time using the Old Disk Server Protocol which 
broadcasts an illegal command in place of the 'Who are you' 
command. The expected response is an error code. 

a. The Old Disk Server Protocol will receive a Results 

message on socket BOh, so issue an End Receive followed by 
a Setup Receive for socket BOh. 



TCmd+Opcode 
TCmd+ResAdr 
TCmd+Sock 



<- lOh (End receive) 

<- address of SndRes 
<- BOh 



SndRes+Rcode <- FFh (initialize result code) 



TCmd+Opcode 

TCmd+ResAdr 

TCmd+Sock 

TCmd+DatAdr 

TCmd+DataLen 



<- FOh (Setup Receive) 

<- address of RcvBO 
<- BOh 
<- SBOMsg 
<- 



TCmd+CrtlLen <- 3 



RcvBO+Rcode 



<- FFh 
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Now broadcast the Find a server message: 



1 TCrad+Opcode 


<- 


4 Oh 


— -+ 

(Send) 1 


1 TCmd+ResAdr 


<- 


address 


i of SndRes | 


1 TCmd+Sock 


<- 


80h 




1 TCmd+DatAdr 


<- 


address 


{ of MsgBuf 1 


1 TCmd+DataLen 


<- 


08h 


(8 bytes) 1 


1 TCmd+CrtlLen 


<- 







j TCmd+Dest 
1 


<- 


FFh 


(Broadcast) | 


1 

1 SndRes+Rcode 


<- 


FFh 




1 
|MsgBuf+Pid 


<- 


OlFEh 




1 MsgBuf +2 


<- 


Olh 


(Find a server) | 


|MsgBuf+3 


<- 


OOOlh 




1 MsgBuf +5 


<- 


OOOOh 




1 MsgBuf +7 


<- 


FFh 


(Illegal coininand) | 



If a message is received, then set Bootsrv. 



Bootsrv <- Rcv80+Src 



■+ 

I 
■+ 



If still no disk server is found, then a message should be 
displayed on the screen, 'No disk server found. ' 

If a disk server is found, then this server becomes the boot 
server used in the steps below. 

2. Get first block of boot code: 

Send directed Read Boot Block command to the boot server 
identified in step (1) . Jimp to the code that is read in. 

If there is an error reading the boot code, then (if 
possible) put a message to the screen and ask the user to 
enter the boot server name or number. This situation would 
occur when the boot code has been placed on some disk 
servers, but not on all. 

For flat cable networks, the ROM simply sends a Read Boot Block 
command. If there is no response in 5 seconds, an error is 
reported. 
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Get rest of boot code: 



Send the appropriate number of Read Boot Block conunands (the 
first boot block should tell you how many more to read) . 
Timeout and retry as for normal disk reads. 

4. Get user name and password: 

Display the Constellation II message (see Figure 4.6). 
Prompt for the user name. 

If the user name entered is <esc>, then boot with no volumes 
mounted, and a blank user name and password. This feature 
allows a user to boot or logon with the Corvus driver 
installed, but no access to the network. The user could 
still execute programs which use the driver to send disk or 
Omninet commands, such as the disk diagnostic. 

Read the user table (NETWORK. USER) from the boot server. 
Encrypt the user name. Search the user table for the user; 
if not found, report an error. 

If user name is found, see if a password is required. If so, 
prompt for password, encrypt it, and validate. If password 
is invalid, reprompt. 

Get user's home disk server name and operating system type 
from the NETWORK. USER table entry. Decrypt the home disk 
server name. 

5. Locate user's home disk server: 

See if user's home server is the one found in step 1. 
If not, broadcast 'Where are you' to find user's home 
disk server ; retry 3 times. If no response in 5 
seconds, report error, and prompt for a server name to 
boot from. This algorithm is very similar to the one 
in Figure 4.3, except for box b. 
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b. Broadcast 'Where are you?', name - home server name 



TCmd+Opcode 
TCmd+ResAdr 
TCmd+Sock 
TCmd+DatAdr 
TCmd+DataLen <- 12h 
TCmd+CrtlLen <- 
TCmd+Dest <- FFh 



<- 40h (Send) 
<- address of SndRes 
<- 8 Oh 

<- address of MsgBuf 
(18 bytes) 



(Broadcast) 



SndRes+Rcode <- FFh 



MsgBuf+Pid <- OlFEh 
MsgBuf +MsgTyp <- 0300h (Where are you) 
MsgBuf+Source <- MyAddr 

MsgBuf+DevType<- Olh (Generic disk server) 
MsgBuf+Name <- (home disk server name - 

unencrypted) 



If the home disk server is not found (i.e., timed out waiting 
for reply) , then prompt the user to enter a server name or 
number: 

Home disk server not found. Enter the name of 
the home disk server, or press <enter> to use the 
default disk server [name]. 

The default disk server is the boot server. You could also 
accept a number as input, and use the number as the address 
of the home disk server. 



6. Tell network you're here. 

Delete any entries for this host number from the Active User 
Table. This is essentially a clean up step, in case previous 
users have not logged off. This step has not yet been 
implemented in any versions of Corvus boot code. 

See if there are duplicate users, and warn the user if there 
are. This check is done to protect users from inadvertently 
sharing access to volvunes. The check is accomplished by 
issuing the FindActive drive command using the (unencrypted) 
user name. If an entry is found, and the Omninet address is 
not the same as MyAddr, then you should send an Omninet Echo 
command to the Omninet address. If you get a reply, then 
warn the user that there may be another user with the same 
name already logged on. 
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The last step is to tell the network you're here. This is 
done by broadcasting a Hello message. You should broadcast 
twice, just to be more sure of the message being received. 



TCmd+Opcode 


<- 


4 Oh (Send) 


TCmd+ResAdr 


<- 


address of SndHes 


TCmd+Sock 


<- 


8 Oh 


TCmd+DatAdr 


<- 


address of MsgBuf 


TCmd+DataLen 


<- 


12h (18 bytes) 


TCmd+CrtlLen 


<- 





TCmd+Dest 


<- 


FFh (Broadcast) 



SndRes+Rcode <- FFh 

MsgBuf +Pid <- OlFEh 

MsgBuf+MsgTyp <- OOOOh (Hello) 

MsgBuf+Source <- MyAddr 

MsgBuf +DevType<- (your device type 

see Table A.l) 
MsgBuf+Name <- (user name - 

unencrypted) 



Load the operating system from the user's boot volume. 

This code searches the DRIVE. ACCESS entries on the user's 
home server for the user's boot volume. If no boot volume 
is found, an error is reported. 

The operating system is normally located in a file with a 
special name, and is found by searching the volume directory 
of the boot volume. 



8. Build the user's mount table (see next section). 



Building the mount table 

Volumes from the user's home server should be mounted first, 
then volumes from other servers. Only volumes from disk 
servers (i.e., not Banks) should be mounted, unless booting 
from the Bank. 

The algorithm for building the mount table is given in Figure 
4.4. 
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Set Server <- 
hone server. 



Set Drive <- l7( 




Figure 4.4: Flowchart of building the mount table 
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a. To see if there is another drive on this server, you should 
bump the current drive number by 1, and send a Get Drive 
Parameters command to the new drive number. If you get a reply, 
and the drive is a physical drive, then continue the loop with 
the new drive number. If you get a reply, and the drive is a 
virtual drive, bump the drive number again, and send another Get 
Drive Parameters command. 

b. To see if there are any more servers, you should start by 
setting the current server address to 0. Send a *Vfho are you' 
message to the current server address. If no reply, or if the 
reply indicates this is not a disk server, then go on the next 
address. If the reply indicates a disk server, then check to 
see if this is the home server. If so, skip it. Exit when the 
Omninet address reaches 64. 

Setting read and write access 

There are several levels of read and write protect scattered 
throughout the Constellation II tables. These are summarized 
below: 

1) DVRec.Glbaccess (set by VOLUME MANAGER) 

"> volume is "invisible". No one can mount this volume. 

1 => volume is "visible". 

2) DVRec.vriteable (set by VOLUME MANAGER) 

■=> volume is read only. No one can write to this volume, 

1 => volume is read/write. 

3) DARec. readonly (set by ACCESS MANAGER) 

=> volume is read/write. 

1 => volume is read only. This user cannot write to 

this volume. 

When mounting a volvime, either at boot time or with the MOUNT 
MANAGER, the following algorithm is used: 

1) If DVRec.Glbaccess « 0, the voliime cannot be mounted. 

2) If DVRec.writeaOsle - 0, the volume is mounted with 
read only capabilities. 

3) If DARec . readonly = 1, the volume is mounted with read 
only capabilities. 

4) If none of the above conditions is true, the volume 
is mounted with read/write capabilities. 
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GlbAccess and writeable are initialized when the volume is 
created. Both are set to 1. Either can be changed with the 
Change option of VOLUME MANAGER. 

Readonly is set when the ACCESS MANAGER is used to grant access 
to a volume. It can be changed with the Change option of ACCESS 
MANAGER. 



Special versions of boot code 

There are two additional functions which the boot code can 
perform. One is single-user boot, and the other is no logon 
boot. 

Single-user boot is a special version of the boot code which 
allows only one user on the network at a time. This code reads 
the Active User Table before prompting for the user name. For 
each entry in the Active User Table which has a host type 
signifying workstation, the boot code sends an Echo command to 
the workstation's address. If there is a response, the boot code 
assumes that another user is currently logged-on, and it refuses 
to boot the new user. 

No logon boot is also a special version of the boot code. With 
this version, the boot code first looks for an entry in the 
Network User table which has a value equal to its host 
transporter address in the Hoststa field. If such an entry is 
found, then the user name is taken from this entry, instead of 
being obtained from a prompt. If no entry is found with the 
current transporter address, then the boot code prompts for a 
user name. Regardless of how the user name is obtained, the boot 
code then proceeds, as described previously, to find the home 
server, the boot volume, and build the mount table. 

No logon boot is used on networks which are configured such that 
certain stations always perform dedicated functions. For 
example, you may have an installation in which you wish to 
dedicate one computer to executing your accounting package. That 
computer can be assigned a particular Omninet address, and an 
entry made in the Network User table for that address. Then 
whenever that computer is booted, it will have a fixed user name, 
and that user can be configured to run only the accounting 
package . 
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Message How determined 

Duplicate host number. Use Echo command 

No disk server found. Broadcast of 'Who are you?' or 

illegal command. 

User not found. Search NETWORK. USER table 

User's operating system From NETWORK. USER table and boot 
type not supported. code 

Incorrect password. From NETWORK. USER table 

Home server not found. From NETWORK. USER table and 'Where 

are you? ' command 

Boot volume not found. From DRIVE. USER table, DRIVE. ACCESS 

table 

Unable to load Directory of boot volume 
operating system. 

Disk read error. Drive off-line, invalid block 

address . 



Figure 4.5: Summary of error conditions during boot 
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* 

CORVUS SYSTEMS 
* CONSTELLATION II 

* * V x.x (yy/zz) 



Please enter your naae: 

Please enter your password: 

«Error messages appear in this line...» 

Figure 4.6a: Screen formats for boot messages (old logo) 



CORVUS 
CONSTELLATION II 



Please enter your name: 

Please enter your password: 

«Error messages appear in this line...» 

Version x.xx Boot server: zz Station: yy 

Figure 4.6b: Screen formats for boot messages (new logo) 



Constellation Software GTI 4-19 



Boot and logon procedure 



CORVUS SYSTEMS 
CONSTELLATION II 

V x.x (yy) 



Please enter your name: 

Please enter your password: 

«Error messages appear in this line...» 

Figure 4.6c: Screen formats for boot messages (new logo) 



Notes for figures 4.6a through 4.6c: 

These are three screen formats currently used by different 
versions of Corvus boot code. You should always try to 
include the following information on the boot screen: 

x.x: the version number of the boot code, 
yy: this computer's Omninet address. 
zz: server number of boot server. 

The boot code should be outputting some sort of message or 
heartbeat (dots across screen) at least every 2 seconds. 
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Chapter 5: User utilities 

Mount manager 

The Mount Manager is a utility which a user can run to change 
which volumes are currently on-line. Functions included are 
listed below: 

Mount a volume, specifying volume name, unit number, and 

write protection 
Unmount a volume, specifying volume name or unit number 
Display the currently mounted volumes 
Display the accessible volumes (i.e., those that can be 

mounted) 
Display user name and transporter address 

In order to provide these functions, the Mount Manager must read 
the Constellation II disk tables, including the Network User 
table, the Drive User table, the Drive Volume table, and the 
Drive Access table. The Mount Manager must also use the Read 
Mount Table and Write Mount Table entry points of the operating 
system driver. 

Mount a volume 

1) Validate the unit number. 

2) Search all Drive Volume Tables for the named volume. Note 
that since the Drive Volume Table is sorted by volume address, 
this must be a sequential search through the entire table. 

3) Find the Drive User entry for the user. 

4) Using the volume address from the Drive Volume Table, and 
the user id from the Drive User Table, find the Drive Access 
entry for this user and volume. 

5) Select the appropriate write protection, as described 
below under the heading Setting read and write access, 

5) Call Read Mount Table to get the current mount table; 
modify the appropriate entry; call Write Mount Table to update 
the driver with the new mount table. 

Unmount a volume 

1) Search all Drive Volume Tables for the named volume. 
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2) Call Read Mount Table to get the current mount table. 
Search the mount table for the entry whose mount information 
matches the address of the named volume. Overwrite this entry 
with zeroes to indicate an unused mount entry. 

3) Call Write Mount Table to update the driver. 

Display mount information 

1) Call Read Mount Table to get the current mount table and 
user information. 

2) Display the appropriate information. For currently 
mounted volumes, you will have to find the volume names by 
searching the appropriate Drive Volume tables. For accessible 
volumes, you will have to search all Drive User tables and 
appropriate Drive Access and Drive Volume tables. 

Setting read and write access 

There are several levels of read/write protect scattered 
throughout the Constellation II tables. These are listed below: 

1) DVRec . Glbaccess (set by VOLUME MANAGER) 

=> volvime is invisible. No one can mount this volume. 

1 => volume is visible. 

2) DVRec. writeable (set by VOLUME MANAGER) 

=> volume is read only. No one can write to this volume, 

1 => volume is read/write. 

3) DARec. readonly (set by ACCESS MANAGER) 

=> volume is read/write. 

1 => volume is read only. This user cannot write to 

this volume. 

When mounting a volume, either at boot time or with the MOUNT 
MANAGER, the following algorithm is used: 

1) If DVRec. Glbaccess ^ o, the volume cannot be mounted. 

2) If DVRec. writeable ■= 0, the volume is mounted with 
read only capabilities. 

3) If DARec . readonly = 1, the volume is mounted with read 
only capabilities. 
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4) If none of the above conditions is true, the volume 
is mounted with read/write capabilities. 

GlbAccess and Writeable are initialized when the volume is 
created. Both are set to 1. Either can be changed with the 
Change option of VOLUME MANAGER. 

Readonly is set when the ACCESS MANAGER is used to grant access 
to a volume. It can be changed with the Change option of ACCESS 
MANAGER. 

Library routines 

(This section lists the ideal set of library routines. See 
Appendix B for a list of the routines provided by Corvus for a 
particular operating system. ) 

Library routines should provide the following functions: 

Semaphore operations 

See Corvus Mass Storage Systems GTI , Chapter 5. 

Pipes operations 

See Corvus Mass Storage Systems GTI, Chapter 6. 

Mount table operations 

FUNCTION UnitAdr( unit: INTEGER; 

VAR voladr: CDAddr; 

VAR read_only BOOLEAN) : BOOLEAN; 

Returns the location and read-write information for the 
volume mounted on the specified unit. Definition of 
CDAddr is: 

TYPE CDAddr " RECORD 
Slot no: INTEGER; 
serverno : INTEGER ; 
dr iveno : INTEGER ; 
Addr: LONGINT; 
END; 
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FUNCTION GetMntInfo( VAR Mntlnfo: MntStuff ): BOOLEAN; 

Returns the mount information as follows: 

TYPE MntStuff = RECORD 

username: string [10]; { unencrypted } 

userpass: string [8]; { encrypted } 

homesrvr: INTEGER; 

homes 1 ot : INTEGER ; 

cardtype: INTEGER; (l=flat cable, 2=0nmiNet) 

useraddr: INTEGER; (user's transporter address ) 

END; 

FUNCTION UnMount( unit: INTEGER ): BOOLEAN; 

Unmounts the volume on the unit specified; 
returns TRUE if successful. 

FUNCTION Mount ( volume: String; unit: INTEGER ): BOOLEAN; 

Mounts the volume named, if user has access; 
returns TRUE if successful. 

Some convention for specifying server and drive number 
must be used. Either the volume name string must include 
a server and drive name, or another function must be 
called to specify server and drive. 



Send Corvus disk command 

See Corvus Mass Storage Systems GTI , Chapter 4. 

Spooler and despooler 

See Corvus Mass Storage Systems GTI, Chapter 6. 

Spool driver 

For those operating systems which support attachable drivers, it 
is possible to write a spool driver which will redirect output 
sent to the printer to the Corvus pipes area. The despooler will 
then print the data on the shared network printer. This section 
summarizes the functions provided by a spool driver. 
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There are usually two entry points to a printer driver: device 
initialization and character write. Device initialization simply 
sets up all the default parameters used by the driver. The write 
call does all the work: 

1) If a pipe is not currently open, then open a pipe with the 
default name. Write the preamble block. Set the pipe open 
flag, and initialize the output buffer. 

2) Put the character in the output buffer. 

3) If the output buffer is full (512 bytes), then write the 
buffer to the disk with a Pipe Write command, and 
reinitialize the output buffer. 

The main problem encountered in writing a spooler driver is 
figuring out when to close the pipe. Corvus has used two 
approaches which both seem to be acceptable in practice: one is 
to use a timeout (that is, if no output has occurred in a fixed 
amount of time, then flush the buffer and close the pipe) ; the 
second is to monitor the output for a defined string; when that 
string is seen, flush the buffer and close the pipe. 

All of the parameters used by the spooler driver are stored in a 
table which can be modified through an entry point in the 
driver. Parameters and suggested defaults are listed below: 

1) pipe name (default "PRINTER") ; 

2) disk server address of disk containing pipes area 
(default is user's home disk server); 

3) contents of preamble block message (default is user name 
concatenated with date and time) ; 

4) timeout value to use in closing the pipe (default is 
15 seconds) ; 

5) string to look for in closing a pipe (default "::"). 
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Overview 

The Constellation II management utilities consist of several 
separate programs which are controlled from a single management 
program known as the Constellation II manager (CC.C2MGR on 
Concept; C2MGR.C0DE on p-system) . 

The Constellation II manager program presents the user with 
several sets of menus; when a user chooses an option, either 
another menu is provided, or a second program is loaded. When 
execution of the second program is completed, control is returned 
to the manager program. 

On Concept, control is transferred to other programs with the 
CALL intrinsic. Under CCOS, when the CALLed program terminates, 
control is returned to the statement following the CALL. 

On p-system, control is transferred to other programs with the 
CHAIN procedure. When an option is selected which requires 
another program to execute, the CHAIN procedure is called twice, 
once to CHAIN to the new program, and once to CHAIN back to 
C2MGR. Then an EXIT (program) statement is executed, which 
transfers control to the new program. When the new program 
terminates, control is transferred to the next statement in the 
CHAIN, which is C2MGR. 

(Note to implementers: All this chaining under p-system is VERY 
slow. There are two alternatives to using CHAIN: one is to use 
the CALLER unit available from NCI, and the other is to make most 
of the programs into units rather than programs. Both of these 
alternatives have been tried, and appear to work. The only 
problem is in phasing in the new versions of the utilities, since 
the old CHAIN versions will not work with versions using either 
CALLER or units . ) 

The main menu of C2MGR currently contains these options: 

Menu option Action 

Drive Management Display Drive Management menu 

Backup Utilities Display Backup menu 
Maintenance Utilities Display Maintenance menu 

Utility Server Display Utility Server menu 

Transfer Manager Invoke Transfer Manager program 

Initialize Drive Invoke System Generation program 

List Drives Update and display Active User Table 

Exit Terminate program 
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Each siib-menu is described below: 



Drive Management 
Menu option 



Action 



User/Device Manager 


Invoke 


Volume Manager 


Invoke 


Access Manager 


Invoke 


Boot Manager 


Invoke 


Select Drive 


Prompt 


List Drives 


Update 


Exit 


return 



User Manager program 
Volume Manager program 
Access Manager program 
Boot Manager program 
for drive name and password 
and display Active User Table 
to outer menu 



Backup Utilities 
Menu option 



Action 



Mirror 

Archival Storage 
Remote Backup 
Select Drive 
List Drives 
Exit 

Maintenance Utilities 
Menu option 



Invoke Mirror program 

Invoke Mirror program, remote option 

Invoke Net Backup program 

same as above 

same as above 

return to outer menu 



Action 



Parameter Manager 

Disk Diagnostic 

OmniDrive Diagnostic 

Bank Diagnostic 

Omninet Test 

Fixit (hidden option) 

Update Utilities 

Select Drive 

List Drives 

Exit 

Utility Server Manager 
Menu option 



Invoke Parameter Manager program 
Invoke Rev B/H Diagnostic program 
Invoke Omnidrive Diagnostic program 
Invoke Bank Diagnostic program 
Invoke Omninet Test program 
Invoke Const II Utility program 
Invoke Utility Update program 
same as above 
same as above 
return to outer menu 



Action 



Printer Service 
Time Service 
Exit 



Invoke Print Server Manager program 
Invoke Time Server Manager program 
return to outer menu 



Each program is described in detail later in this chapter, except 
for the Utility Server Manager options which are covered in 
Chapter 7. 
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Menu file 



The menus actually displayed and the actions taken for each 
option are controlled by a text file called C2. MENU. TEXT. Each 
line in this file has the following format: 



Column 1-2: 
Colximn 4-5: 
Column 6: 



Column 7-34: 



Column 35-36: 
Column 37-44: 
Column 45-46: 
Column 47-54: 
Column 56-57: 

Coluian 58-71: 
Column 75: 

Column 76: 



Column 77-86: 
Column 90: 



Menu number on which this option is displayed. 

Relative order of this option in menu. 

"b" indicates to print a blank line before 

printing this option. "q" indicates that this is 

a hidden option, and the option label should not 

be displayed. 

Option label. The first character (colvimn 7) must 

be the character that the user presses to select 

this option. 

Softkey number. 

Softkey label. 

Softkey number. 

Softkey label. 

Nximber of the menu to be displayed if this option 

is selected. 

Program to be invoked if this option is selected. 

"n" indicates that the current disk server 

information should NOT be displayed on the screen. 

"Y" indicates that the selected drive information 

should be passed to the invoked program; "-" 

indicates that the selected drive information 

should NOT be passed to the invoked program. 

Selected drive information is discussed below. 

Additional parameters to be passed to program. 

"/" to indicate end-of-line. 
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Here is a portion of a C2. MENU. TEXT file, with column numbers 
indicated. It shows the file contents for the main menu and for 
the Drive Management sub-menu. 









112 2 3 


3 4 


4 5 


5 6 6 


7 


1. . 


K 




0. . . .5. . . .0. . . .5. . . .0. . . 


A ' ^ M A A A Vj M M M 


.5. . . .0. . . . 


5. . . .0. . . .5//^- 


01 


lObD 


— 


Drive Management 


9 ^ir V V V » ^* • • W 

lODrive 


©Manager 


02x 


- 


01 


20 B 


- 


Backup Utilities 




01 Backup 


03x 


- 


01 


30 M 


- 


Maintenance Utilities 




02Maint 


04X 


- 


01 


40qC 


- 


Configure System 






05x 


n- 


01 


50bU 


- 


Utility Server Manager 


13Utility 


03Server 


06x 


n- 


01 


55 T 


- 


Transfer Manager 


14Transfer04Manager 


OOXFRMGR 


- 


01 


6 Obi 


- 


Initialize Drive 


15Init 


05Drive 


OOSYSGEN 


- 


01 


80 L 


- 


List Drives 


17List 


07 Drives 


OOX 


- 


01 


85 H 


- 


Help 




08Help 


OOX 


- 


01 


90 E 


- 


Exit 




19Exit 


OOx 


- 


02 


lObU 


- 


User/Device Manager 


lOUser 


OOManager 


OOUSERMGR 


Y 


02 


20 V 


- 


Volume Manager 


llVolume 


OlManager 


OODRIVEMGR 


Y 


02 


30 A 


- 


Access Manager 


12Access 


02Manager 


OOACCMGR 


Y 


02 


40bB 


- 


Boot Manager 


14Boot 


04Manager 


OOBOOTMGR 


Y 


02 


70bS 


- 


Select Drive 


ISSelect 


05 Drive 


OOx 


- 


02 


80 L 


- 


List Drives 


17List 


07Drives 


OOx 


- 


02 


90 E 


— 


Exit 




09Exit 


OlX 


- 



On startup, C2MGR reads the entire C2. MENU. TEXT file, and builds 
an internal data structure. This structure allows a maximum of 
10 options per menu, and a maximum of 10 menus. 

Menu 1 is displayed, and the user is prompted to enter a 
character. The character is compared to each of the possible 
choices for the current menu (colvimn 7) ; if it matches, then one 
of the following actions is taken: 

(a) Display new menu (menu number > 0) . 

(b) Execute predefined option (menu nvimber=0, program name="x") 

(c) Invoke new program (menu number=0, program name<>"x") 
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The predefined options include: 



L - List Drives: Updates the Active User Table using the 
algorithm described in Figure 2.13; then displays, for each disk 
server entry, information on each drive connected to the server. 

S - Select Drive: Prompts user for a server name, drive 
name, and drive password. This information will be passed as a 
parameter to any invoked programs. 

E - Exit: Exits the program. 

H - Help: Displays the Help file, C2. HELP. TEXT. 

If a new program is to be invoked, then a parameter string is 
built, consisting of the selected drive information, if required 
(column 76«"y"), followed by any additional parameters indicated 
in columns 77-86. If selected drive information is required, and 
no drive has been selected, then the user is prompted to select a 
drive before the new program is invoked. 

For p-system, the selected drive information is also included on 
the second CHAIN, which will reexecute C2MGR. A second parameter 
specified on this CHAIN tells the C2MGR program which menu it 
should display on start-up. A "D" tells it to display the Drive 
Management menu; an "X" tells it to display the main menu. This 
information is passed to C2MGR so that the effect of the CHAIN is 
similar to that obtained using CALL on CCOS: the user is 
returned to the point in C2MGR where the second program was 
invoked . 

The selected drive information is passed in the following format: 

3 digits indicating slot number (use 001 for machines with 

only one slot) . 
3 digits of zero. 

3 digits indicating server address. 
3 digits indicating drive number. 
8 character drive password (unencrypted) . 

Each field is separated by a "/". For instance, the string 

001/000/000/001/S 

indicates slot 1, server 0, drive 1, with password "S". 

Note that while the user selects the drive by indicating the 
server and drive names, the corresponding addresses are passed to 
the program. 
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Programs may be invoked from the command line by entering the 
appropriate parameter string. For instance, the following 
command executes the User Manager program on CCOS: 

USERMGR 005/000/000/001/S 

The following command executes the User Manager program on 
p-system: 

XUSERMGR I="001/000/000/001/S," 

Options file 

Several of the Constellation II programs present a list of 
alternatives when prompting for specific input. The contents of 
these lists are read from an options file called C2. MISC. TEXT. 
Currently, the following options are supported: 

Device type, from Table A.l (generic types only) 
Volume type, from Table A. 2 
Operating system type, from Table A. 3 
Boot type, from Table A. 4 

The options file contains a text description of the option and 
its corresponding integer indicator. It usually contains a 
subset of the information included in Tables A.l through A. 4. On 
program start-up, an internal data structure is built reflecting 
the contents of this file; the structure allows 18 options per 
table, vnienever the user is prompted to specify a volume type, 
for instance, the appropriate text descriptions are displayed, 
and the user may enter a substring which maps uniquely to one of 
the choices. The corresponding integer is then used in the Drive 
Volume table entry. Similarly, whenever a Drive Volume table 
entry is displayed, the integer from the entry is mapped to the 
appropriate text description, and the text is displayed. 

Each line from the options file has the following format: 

Coliimn 1; Table indicator: 
D - device type 
V - volume type 
O - operating system type 
B - boot type 

1 or more blanks, and then an integer value 

1 or more blanks, and then either an "x" or a "." If its an "x", 
then the next 20 characters are a text description. 
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For operating system type, additional information is included, 
which indicates what the drive specifiers are for the particular 
operating system. This information includes two integers, as 
described below: 

First integer, preceded by a •'.", is drive specifier type: 
1: Letters "A", "B", "C", ... 
2: p-system units: 4, 5, 9, 10, ... 
3 : Units nximbered from : , 1 , 2 , ... 
4: Apple DOS slot and drive numbers: 01, 02, 11, 12, . 

Second integer: maximum number of unit specifiers 

Then there are 1 or more blanks, followed by an "x", followed by 
a text description. 

Here is a sample of the C2. MISC. TEXT file: 



B 


4 


xConcept 




B 


9 


xIBMPC 




B 


18 


xPrintsrv 


H 


6 


xBank 




H 


2 


xDiskServer 


H 


3 


xPrintServer 


H 


1 


xUserWorkstation 





16 


.2 


29 xCCOS 





4 


.3 


10 xMSDOS 





17 


.2 


12 XUCSDIV.O 


V 


14 


XCCOS 




V 


3 


XMSDOS 




V 


1 


XUCSD 





Update file (install new versions of utilities) 

For CCOS, new versions of the utilities are installed either 
manually, or by executing an EXEC file which invokes the filer. 

For p-system, Corvus does not license the Filer, so we have 
provided our own Update program to copy and remove files. This 
program is driven by a text file called SYSTEM. CONTENT. Each 
line in the SYSTEM. CONTENT file is a command; the commands and 
their format are listed below: 
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Cosmiand formats (showing columns) : 



1. , 


1 
, .5. . . .0 


2 


3 



4 
.0 


5 


5 


6 
. . 


c 


<Fnamel> 




<Fname2> 






/ 


• • w 


D 


<Fname> 




/ 










K 


<Volname> 




/ 










L 


<Volname> 




/ 










M 


<Fnamel> 




<Fname2> 






/ 




X 


<Fname> 




/ 










N 


<Volname> 




/ 











Command definitions: 

C: Copy file; <Fnamel> = source; <Fname2> >= destination 

D: Delete file <Fname> 

K: Krunch volume <Volname> 

L: List volume <Volname> 

M: Merge <Fnamel> ■» <Fnamel>+<Fname2> 

X: Execute program <Fname> 

N: Prompt user to insert floppy called <Volname> 

Commands can come in any order, except the last command in a file 
must be either an "N" command or an "X" command. If there are no 
more floppies in the set, then <Volname> is blank. 

Blank lines between commands are allowed. There must always be a 
character in (or past) the column marked with '/'' this character 
marks the end of the command. 

<Fname> is a fully qualified file name, i.e., it can include a 
volume name. <Volname> is a volume name, including the •/' o^r 
• : • required by Concept and UCSD respectively. 
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The Merge command is currently unimplemented, but was intended to 
be used to merge new lines into the menu file or the options 
file. It assumes that both files are sorted, and merges the new 
file <Fname2> into the old one <Fnamel>, discarding duplicate 
lines. 

The Copy command compares the dates of the source and 
destination files; if the source file is older than the 
destination file, the copy is not performed. If there is no room 
to copy a file, the volvime is krunched, and the user is prompted 
to reboot. The user can then execute the update again. 

The Update Utility also states that a copy command may have a * 
in column 2 . This feature was used to indicate that the program 
should reboot after the copy and was used for replacing the 
UPDATE program itself, or other critical programs. However, 
since the Update Utility was changed to copy a source file if the 
source date was equal to the destination date, this "*" feature 
should no longer be used, since it will prevent the update from 
ever completing successfully. 

Here is a listing of a SYSTEM. CONTENT file: 

...5....0 5 

C CORMS22:ddiag.code IBMSYSrDDIAG.CODE / 

C CORMS22:DIAG.DATA IBMSYStDIAG.DATA / 

C CORMS22:CF18.4ap.DATA IBMSYS :CF18 . 4AP.DATA / 

C CORMS22:OTEST.CODE IBMSYS tOTEST. CODE / 

C CORMS22;odiag.code IBMSYS :ODIAG. CODE / 

C CORMS22:OD.DIAG.DATA IBMSYS :OD.DI AG. DATA / 

C CORMS22:FODR1.6.DATA IBMSYS : FODRl . 6 . DATA / 

N CORMS23: / 

Program descriptions 

The next few pages describe each of the current Constellation II 
management programs. Each description gives the name of the 
program code file for Concept and p-system, and a brief summary 
of what the program is used for. Then each option is described 
by listing the internal steps performed by the program. 
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Concept p-system 
User Manager USERMGR USERMGR.CODE 

Used to add, delete, and change users. Updates entries on the 
first drive of each disk server on the network. 

Add user Prompt for user name, password, home server, 

and OS type. Build a NETWORK. USER entry. Add the 
entry to the selected drive. Check all other disk 
servers on network; if entry does not exist, add 
it; if entry does exist, replace it. 

Remove user.. Prompt for user name. Find the NETWORK. USER entry 
on the current server, and display its contents. 
For each drive on the current server, find the 
DRIVE. USER entry for the specified user; if found, 
delete all DRIVE. ACCESS entries with the user's 
userid. Remove the NETWORK. USER entry. Repeat for 
each disk server on the network. 

Change user.. Prompt for user name. Find the NETWORK. USER entry, 
and display its contents. Prompt for new password, 
home server, and OS type. Replace the entry with 
the new information. Check all other disk servers 
on network; if entry exists, replace it; if entry 
does not exist, add it. 

List users... Dislay each entry in the current NETWORK. USER 
table. 
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Volume Manager 



Concept 
DRIVEMGR 



p-system 
DRIVEMGR. CODE 

Works on selected drive 



Used to add, delete, and change volumes, 
only. 

Add volvime... Build a table of free spaces on drive. Prompt for 
and validate volume name, length, starting location, 
volume type. Build a DRIVE. VOLUME table entry, 
with RW access; add the entry. Format the volume. 
Build a DRIVE. ACCESS table entry for userid 1 and 
the new volxime; add the entry. 

Remove volume Prompt for volume name. Find the DRIVE. VOLUME 
entry, and display its contents. Remove all 
DRIVE. ACCESS entries with that volume's address. 
Remove the DRIVE. VOLUME entry. 

Change volume Prompt for volume name. Find the DRIVE. VOLUME 

entry, and display its contents. Prompt for new 
name, RW protection. Change the entry. Note that 
nothing in the volume itself is modified. 

List volumes. Display each entry in the current DRIVE. VOLUME 
table. 

Extended list Prompt for a volxime type. Display each entry with 
that volume type in the current DRIVE. VOLUME table, 
along with pertinent operating system dependent 
information extracted from the volume itself. 
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Concept p-system 
Access Manager ACCMGR ACCMGR.CODE 

Used to specify which users have access to which volumes, and to 
set default boot conditions. Works on one drive at a time. 

Next user.... Prompt for user name. Find the NETWORK. USER 

entry. Find the DRIVE. USER entry; if not there, 
add one. 

Grant access. Prompt for volume name. Find the DRIVE. VOLUME 
entry. Prompt user for additional information. 
Build a DRIVE. ACCESS entry; add the entry. 

Remove access Prompt for volume name. Find the DRIVE. ACCESS 
entry; delete it. 

Change access Prompt for volume name. Find the DRIVE. ACCESS 

entry. Prompt user for new information; replace 
DRIVE. ACCESS entry. 

List access.. Find all DRIVE. ACCESS entries. For each entry, 
find the matching DRIVE. VOLUME entry. Print the 
appropriate information. 

Help Display Help options: 

View volxame For each DRIVE. VOLUME entry, print the volume 

name. Find the matching DRIVE. ACCESS entry; if one 
exists, print an "x" indicating access for this 
user. 

User list.. For each NETWORK. USER entry, print the user name. 
Find the matching DRIVE. USER entry; if one exists, 
print the userid number. 
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Concept p-system 
Boot Manager BOOTMGR BOOTMGR.CODE 

Used to add, delete, and display the table of boot information 
used by the boot command. Updates information on the first drive 
on each disk server on a network. 

Add file..... Copy a boot file to the Corvus volume. Update the 
appropriate entry in the SYSTEM. BOOT table to point 
to the new boot file. Repeat for all servers on 
network. 

Remove file.. Delete the appropriate file from the Corvus 
volume. Update the appropriate entry in the 
SYSTEM. BOOT table to FFh. Repeat for all servers 
on network. 

List files... Print each non-empty entry from the SYSTEM. BOOT 
table. Print the computer type associated with 
that entry. Print the file name from the directory 
entry with the address indicated in the SYSTEM. BOOT 
entry. 
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Concept p-system 
System Generation SYSGEN SYSGEN.CODE 

To create the Corvus volume, and to optionally set up for 
operation system installation. Works mainly on selected drive, 
but adds users and boot files to the first drive on each disk 
server on the network. 

Init Prompt for location and length of Corvus volume. 

Decide on sizes for SYSTEM. BOOT, NETWORK. USER, 
DRIVE. USER, DRIVE. VOLUME, and DRIVE. ACCESS tables, 
based on length of Corvus volume. 
Build DRIVE. INFO block; write it. Copy the boot 
code to the proper location in the Corvus volume. 
Build a directory for the Corvus volume; write it. 
Write FFh to all table entries (initial value). 
Create NETWORK. USER entries for all default users. 
Create DRIVE. USER entries for all users. Create a 
DRIVE. VOLUME entry for Corvus volume, and any 
operating system volumes. Create a DRIVE. ACCESS 
entry for each default user-volume access. 

Modify Display additional options: 

Mix Find Corvus volume. Add entries for new users, 

volumes and accesses. Add new boot code. 

Add Find an unused area of the drive. Proceed as for 

Init. 

Upgrade.... Same as for Add. 

Install.... Copy operating system dependent files to 
appropriate volume. 
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Concept p-system 

Mirror MIRROR MIRROR. CODE 

Archival storage MIRROR "R" MIRROR. CODE "R" 

Network Backup MBACKUP MBACKUP.CODE 

Utilities for backing up and restoring data with Corvus Mirror (TM) 
hardware . 



Constellation Software GTI 6-15 



Management utilities 

Concept p-system 
Parameter Manager PARMGR PAKMGR.CODE 

Used to maintain the pipes and semaphore areas of the specified 
drive. 

Pipes Display additional options: 

Init Find a volume called PIPES. Send a Pipe Area 

Initialize command using the (starting address+6) 
and (length-6) of the PIPES volume. 

Clear Send a Pipe Status 2 command to get the pipe 

pointer table. Send a Pipe Area Initialize command 
using the data received from the Pipe Status 
command . 

Close Send a Pipe Close read command. If error, send a 

Pipe Close write command. 

Purge Send a Pipe Close purge command. 

List Send a Pipe Status 1 command to get the pipe name 

table. Send a Pipe Status 2 command to get the 
pipe pointer table. Format and print the results. 

Semaphores . . . Display additional options : 

Init Send a Semaphore Initialize command. 

Lock Send a Semaphore Lock command. 

Unlock Send a Semaphore Unlock command. 

Status Send a Semaphore Status command. Print the 

results. 

MUX Put drive in prep mode. Send a Read Corvus Firmware 

command. Modify MUX table and parameters as 
specified by user. Send a Write Corvus Firmware 
command. Take drive out of prep mode. 
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Concept 


p-system 


DDIAG 


DDIAG. CODE 


ODIAG 


ODIAG. CODE 


BDIAG 


BDIAG. CODE 


MDIAG 


MDIAG. CODE 



Rev B/H Diagnostic 
omnidrive diagnostic 
Bank diagnostic 
Combined diagnostics 

Utility programs used to format the drive, update firmware, 
modify drive or tape parameters, etc. MDIAG is a later version 
which combines the functions of DDIAG, ODIAG, and BDIAG. 



omninet Test 



Concept 
OTEST 



p-system 
OTEST. CODE 



Test program used to verify reliable operation of Omninet 
hardware . 



Start . 



Who. 



Prompt for destination node address and niomber of 

times to send. Use Omninet Send command to send a 
fixed message, and wait for a reply. Count number 
of retries and number of replies. Display results. 

Send Omninet Echo command to every possible node 

address (0 to 63) . Print the node number if you 
get a response, otherwise print a "." 

Additionally, the program uses the Omninet Setup Receive command 
to set up a socket for receiving messages from other computers 
which may be running the Omninet Test program. Each time a 
message is received, a count is incremented, and the socket is 
set up again. 



Const II Utility 



Concept 

FIXIT 



p-system 
FIXIT. CODE 



Utility program used to rewrite server and drive name and 
password, in case you forget it. The program reads the Drive 
Information Block, displays the old information, prompts for new 
information, and rewrites the Drive Information Block. 
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Concept p-system 
Update Utilities - UPDATE. CODE 

Reads SYSTEM. CONTENT file from specified floppy and executes 
commands contained in it. This option is used to install new or 
updated copies of the Constellation II management programs. This 
is a batch program, controlled entirely by the SYSTEM. CONTENT 
file, except when it prompts the user to insert a new floppy. 
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Concept p-system 
Transfer Manager XFRMGR XFRMGR.CODE 

Used primarily to backup drives to Bank, and to restore. 

Drive to Image Copy Create a DRIVE. VOLUME entry for the image. 

Add the entry. Copy all blocks up to the 
last used block from the drive to the image 
volume, using absolute block read and write 
commands . 

Image to Drive Copy Locate the image volvime. Copy the entire 

image to the destination drive, starting at 
block 0, using absolute block read and write 
commands . 

Remove an Image.... Prompt for image name. Find the DRIVE. VOLUME 

entry, and display its contents. Remove the 
DRIVE. VOLUME entry. 

List Images Read DRIVE. VOLUME table and display all 

image volumes. If specified, read the 
DRIVE. VOLUME table from selected image, and 
display all volumes. 

Volvime Copy Prompt for source volume location. Prompt 

for destination volume location. Locate 
DRIVE. VOLUME entry for source; create and add 
DRIVE. VOLUME entry for destination. Use 
absolute block read and write to copy 
volxome contents. 

Media Copy Use Get Drive Parameters command to get 

source drive size and destination drive size. 
If source drive is Constellation II format, 
then read DRIVE. VOLUME table to get size of 
data on source drive. If source size is less 
than or equal to destination size, then copy 
all blocks from source to destination, using 
absolute block read and write commands. 

Show Results Display contents of specified results file. 
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Constellation II library routines 

Both CCOS and p-system support the concept of units, which are 
separately compiled procedures and functions. Many of the units 
used by Constellation II are of general use to software 
developers. The units used by Constellation II are described 
in this section. 

Error reporting (ERRORS, ERRREPORTS) 

These two units are used for all error reporting. Unit Errors 
contains only constant declarations, and details all of the error 
messages produced by Constellation II utilities. Unit ErrReports 
contains the procedures used to print these error messages to the 
screen. 

Table manipulation (CVDEFN, CVTABS/ TBLRTNS, CVTUTILS) 

These units are used for Constellation II table manipulation. 
The units Cvdefn and CVtabs contain declarations for all the 
table structures. Unit Tblrtns contains low-level routines for 
table search, insertion, deletion, replacement, and listing. 
Unit CVTUtils contains higher level routines for operations on 
specific tables. All of the Constellation II programs use 
CVTUtils to access the tables; CVTUtils in turn calls the 
routines in TblRtns. The procedures in TblRtns are never called 
directly, except by CVTUtils. 

CVdefn and CVTabs are separate units for CCOS; for p-system, the 
declarations contained in CVdefn and CVTabs are included in unit 
CVTUtils instead. 



Encryption (C2Utill, CVCRYPT) 

All name and password encryption and decryption is handled by 
these routines. There are also routines in C2Utill which convert 
from string data type to the internal Name and Pas$word data 
types . 

For CCOS, there is only one unit, C2Utill, for encryption. 
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Drive selection (NIUTIL, C2UTIL3, C2U3) 

These routines handle the menu functions Select Drive and List 
Drives . 

For CCOS, units NlUtil and C2U3 are used. For p-systein, units 
NlUtil and C2Util3 are used. 

Options file (C2UTIL2, C2U2) 

These routines handle reading the options file, prompting the 
user with appropriate options, and converting table information 
into text. 

For CCOS, the unit is called C2U2. For p-system, the unit is 
called C2Util2. 



Volume formatting (FMTERS) 

This unit handles all operating system specific volume 
formatting. Whenever a new volume type is defined, the code to 
format the volume must be added to this unit. 



Console I/O (CCCRTIO, UCCRTIO) 

These routines handle all i/o to the screen. CCCrtIO is for 
CCOS; UCCrtIO is for p-system. 

Drive communication (CCDRVIO, UCDRVIO) 

These routines are used to send drive commands directly to a 
drive. In addition to absolute disk reads and writes, these 
commands include the pipes and semaphores commands, and drive 
status commands. CCDrvIO is used for CCOS; UCDrvIO is ufeed for 
p-system. 

Omninet operations (CCOTCIO, CCOMNIIO, UCOMNIIO) 

These routines are used to issue Omninet commands, such as Send 
and Setup Receive. Units CCOtcIO and CCOmnilO are used by CCOS; 
unit CCOtcIO supercedes CCOmnilO; unit UCOmnilO is used by 
p-system. 
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Chapter 7: Utility server 



This chapter describes the original version of the Utility Server 
software. This software consists of two pieces: the utility 
server software which runs on the Utility server hardware, and 
the management programs which run on some host machine on the 
network. It is assumed that you have read the Utility Server 
Manager's Guide for your computer. 

Utility server software 

The Utility server software provides two functions: printer 
despooling and time stamping. The server loads and executes a 
program on power-up; this program simply loops, looking for pipes 
to print, and updating its internal timer variable periodically. 
The despooler function assumes that any pipes it is to print 
contain the preamble block described in the Corvus Mass Storage 
System GTI , Chapter 6. 

Corvus has chosen to use the Version II p-system as the operating 
system executing on the Utility server. The Utility server 
software therefore includes the following files: 

File name Description 

P. SERVER. BOOT Boot code 

SYSTEM. COMSRV p-system interpreter with custom BIOS 

SYSTEM. PASCAL Version II p-system operating system 

SYSTEM. MISCINFO Version II miscinfo file 

SYSTEM. STARTUP Utility server program 

The Utility server uses Constellation II boot protocol. That is, 
the ROM on the utility server broadcasts a Constellation II Read 
Boot Block command on power up. The Utility Server boot code 
must be installed on all disk servers on the network, as a boot 
file in the Corvus volume and with an entry in the System Boot 
table. 

All of the other Utility server files are located in a volume 
pointed to by the boot code file. This volume is a standard UCSD 
volume, and must contain all of the files listed above. In 
addition, the volume contains printer configuration files used by 
the despooling function. These files consist of an index file 
P.SERV.TBL, and one or more data files. Each data file has a 
name of the form P.CONFG.xxxxxxx, where xxxxxxx is a name 
assigned by the user who set up the configuration file. 

The P.SERV.TBL file is one block long, and consists of 64 
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8-byte entries. Each of the 64 entries maps to the Omninet 
addresses to 63, and contains the suffix of the configuration 
file assigned to the Utility server at the corresponding Omninet 
address. For instance, if entry number 10 contains the 
characters ".UTILl ", then the Utility server located at Omninet 
address 10 will look for its configuration information in the 
file named P.CONFG.UTILl. 

Each configuration file contains information for each of the 
three printers that can be connected to the utility server, in 
the following format: 



P . CONFG . xxxxxxx file 
(1 block) 



byte 


Description 


. 1 


0| 


Info for serial 


'— + 


< 


printer 1 


< 


> 




> 


391 




1 


40| 


Info for serial 


'— + 


< 


printer 2 


< 


> 




> 


791 




1 


80| 


Info for parallel 


'— + 


< 


printer 


< 


> 




> 


119 1 




1 


120| 


Timer information 


'""T 


< 




< 


> 




> 


143 1 




— ^ 


144 1 


Unused 


'^^ 


< 




< 


> 




> 


5111 
+. 




- + 



The format of the printer 
information is shown below. 



The format of the timer 
information is shown below. 
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Printer info entry 
(40 bytes) 

byte Description 

+ — + 

I Pipe name | 

< (first byte is length; < 

> maximum 20 chars) > 

201 I 

+ — „ „ 4. 

21 1 Unused | 
+ . + 

22 1 Device type lsb| Device type: 

-+- -+ 1 -> console 

23 1 msb| 2 -> line printer 

+ ■ h 3 -> none 

24 I Device active flag lsb| 4 -> file 

-+- -> not active -+ 5 -> modem 
25 1 1 -> active msb| 
+ , + 

26 1 Line feed flag Isbl 

-+- -> line feeds off -+ 

27 I 1 -> line feeds on msb| 
+ — „ . + 

28 I Max lines per page lsb| 
-+- -+ 

29 1 msb| 
+ . + 

30 1 Tab spacing lsb| 

-+- -+ Baud rate: 

31 1 msb| -> 300 baud 
+___ . + I -> 600 baud 

32 1 Baud rate lsb| 2 -> 1200 baud 

-+- -+ 3 -> 2400 baud 

33 I msb| 4 -> 4800 baud 
+ • + 5 -> 9600 baud 

34 I Character size lsb| 

-+- -> 7 bits -+ Parity: 

35 1 1 -> 8 bits msb| -> parity disabled 
+ . . + 1 _> odd 

36 1 Parity lsb| 2 --> even 

-+- -+ 
37 1 msbj Handshake: 
+ — _, + -> line/cts/inverted 

38 1 Handshake lsb| 1 -> line/cts/normal 

-+- -+ 2 -> line/dcd/ inverted 
39 1 msb| 3 -> line/dcd/normal 
+ + 4 -> xon/xoff 



Constellation Software GTI 



7-3 



utility Server 

Timer information 

byte Description Further explanation 

+ + 

120| 02h I 
+ + 

1211 hour - 1st digit | ASCII: 00, 01, ..., 23 

-+- -+ 
122 I hour - 2nd digit | 
+ + 

12 3 1 Unused | 
+ + 

124 I 02h I 

+ + 

125 1 minute - 1st digit | ASCII: 00, 01, ..., 59 

-+- -+ 

126 1 minute - 2nd digit | 

+ + 

12 7 I Unused | 

+ + 

128 1 Day of week Isb | integer 0..6 

-+- -+ 

129 I msb I 

+ + 

1301 Day Isb I integer 1..31 

-+- -+ 

1311 msb I 

+ + 

132 1 03h I 

+ -+ 

133 1 Month 1st char | ASCII: JAN, FEB, MAR, ... 

I I 

135 I 3rd char | 

+ + 

136 1 04h I 

+ + 

137 1 Year 1st char | ASCII: 1983, 1984, ... 

I I 

140 I 4th char | 

+ + 

141 1 Unused | 

+ + 

142 1 Valid flag Isb | 1 -> timer information is valid 
-+- -+ -> timer information is not 

143 1 msb I valid 

+ + 
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The file P. SERVER. BOOT is modified on installation to include the 
location of the Utility server volume. This information is 
located in block of the file, in bytes 18 through 22. Included 
are the drive number on which the volume is located, the starting 
address of the volume, and the (ending address+1) of the volume. 
This information is in the old Constellation I format; that is, 
the upper 3 bits of the msb of the address contain the drive 
number, and both addresses are divided by 8. For example, if 
the Utility server volume is located on drive 1, starting at 
block 1032, and ending at block 1183, then the contents of bytes 
18 through 22 would be as shown below: 

_ — + + 

01 I 

< < 

> > 

17 1 I 

- — + + 

18 1 20h (drive number) | bits 7.. 5 ~> 1 
+ + 

19 1 20h (drive number +| bits 7.. 5 -> 1 
-+- -+ 

20 1 81h starting addr) | 0081h * 8 -> 1032 
- — + + 

21 1 OOh (ending addr) | 
-+- -+ 

22 I 94h I 0094h * 8 -> 1184 

- — + + 

23| I 

< < 

> > 

5111 I 

+ + 

Note that the disk server address of the Utility server volume is 
not included. For this reason, the Utility server volume must 
always be on disk server 0. 
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Management Utilities 

The Management utilities include two programs: 
Manager and Time Server Manager. 



Print Server 



Print Seirver Manager 



Concept 
PSMGR 



p-system 
PSMGR. CODE 



Used to install the Utility server boot code, and to maintain 
the printer configuration tables. 



Install. . . 



Prompt for name of volume containing Utility server 
files. Read file P. SERVER. BOOT and write volume 
location information into it. Write out file 
BOOT . PRINTSRV . Invoke the Boot Manager program so 
that the user can install the BOOT . PRINTSRV file on 
all disk servers. 



Config. . . . Prompt for name of configuration file. Prompt for 
printer port. If configuration file already exists, 
and there is an entry for the specified port, then 
display the information. Prompt user for new 
information. Build printer information entry. Write 
P . CONFG . xxxxxx file. Prompt user for Utility server 
address. Update entry in P.SERV.TBL file. 



Time Server Manager 



Concept 
TSMGR 



p-system 
TSMGR. CODE 



Used to reset the Utility server clock. 



Read P . CONFG . xxxxxxx file for specified server, 
Update timer information as specified by user. 
Write out P. CONFG. xxxxxxx file. 
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Table A.l 
Constellation Device Types 

Specific types are indented below their generic type. 

Value Meaning 



01 Generic disk device, booting; Corvus disk server 

02 Generic Print Server 

03 Reserved 

04 Mirror Server 

05 Bank 

06 Oitinidrive (generic type = 01) 
07-OFh Reserved. 

lOh Generic disk device, non-booting 

llh-lFh Reserved for future mass storage devices. 

20h-3Fh Workstations. Workstations are Constellation 
Boot number plus 20. 



2 Oh 


Generic Workstation D( 


21h 


Apple II 


25h 


Corvus Concept 


29h 


IBM/PC or IBM/XT 


2Ah 


Xerox 82 


2Bh 


Zenith H89 


2Ch 


NEC PC8000 


2Dh 


Commodore PET 


2 Eh 


Atari 800 


2Fh 


TRS-80 Model I 


3 Oh 


TRS-80 Model II 


31h 


LSI-11 


33h 


Apple /// 


34h 


DEC Rainbow 


35h 


TI Professional 


3 6h 


Zenith Z-100 


37h 


Corvus Concept Plus 


38h 


Corvus Companion 


39h 


Apple Macintosh 


3Ah 


Sony SMC-7086 



40h-5Fh Reserved for future workstations. 
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60h-7Fh Operating system types. Operating system types 
are Constellation operating system number plus 
60h. 



61h 


Apple Pascal 


62h 


Apple DOS 3.3 


63h 


UCSD Pascal version 2.x 


64h 


MS-DOS 1.x 


65h 


Apple SOS 


66h 


Apple Pascal Runtime 


67h 


CP/M 80 


68h 


RT-11 


69h 


RSX-11 


6Ah 


PET DOS 


6Bh 


NEWDOS (TRS-80 Mod I/III) 


6Ch 


NEWDOS-80 (TRS-80 Mod I/III) 


6Dh 


Atari DOS 2.0 


6Eh 


UNIX System 3 


6Fh 


CP/M 86 


70h 


CCOS (Corvus Concept) 


71h 


Constellation II Pascal IV. x 


72h 


CP/M 68 


73h 


NCI p-systera 


74h 


Softech p-system IV. 1 


75h 


Apple ProDOS 


76h 


Apple Macintosh 


77h 


UNIX System 5 


78h 


Apple II CP/M 


80n-8Fh 


Gateways 


8 Oh 


Generic gateway 


81h 


SNA gateway 



90h-9Fh Reserved. 

A0h-A8h Z80 based utility servers 

AOh Generic Utility Server II server 
Alh Enhanced print service 
A2h Simple pipes bridge 

A9h-AFh Reserved for future servers 

BOh-FEh Reserved for future use 

FFh Any device. 
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Table 


A. 2 




Volume 


types 


Code 


Directory type 


Mnemonic 





Invalid 


INVALID 


1 


UCSD 


UCSD 


2 


CP/M 


CPM 


3 


MS DOS 


MS DOS 


4 


Pet 


Pet 


5 


Apple DOS 3.3 


DOS3.3 


6 


Atari DOS 2.0 


ATARI 


7 


RT-11 


RTll 


8 


RSX-11 


RSXll 


9 


NEWDOS 


NEWDOS 


10 


NEWDOS-80 


NEWBO 


11 


UNIX 


UNIX 


12 


Apple III SOS 


A3S0S 


13 


unused 




14 


Concept OS 


CCOS 


15 


unused 




16 
17 
18 
19 


reserved (blocks 0-8) 
drive image (normal) 
drive image (invalid) 
drive image (condensed) 


20 


Softech AFS 


AFS 


21 
22 


Apple PRODOS 
Macintosh 


PRODOS 
MAC 



RESERVED 

IMAGE 

INVIMAGE 
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Table A. 3 
Operating System Types 


Code 


Operating system 


Mnemonic 


1 
6 
3 
17 
19 
20 
16 


Apple Pascal 
Apple run-time 
UCSD II. 
Const I I IV. 
NCI IV. 
So f tech IV. 
Concept OS 


A2Pascal 

A2 Runtime 

UCSDII 

C2IV.0 

NCIIV.O 

SOFTECHIVO 

CCOS 


7 
15 
18 
24 


CP/M 
CP/M-86 
CP/M- 6 8 
A2CP/M 


CP/M 
CP/M-86 
CP/M- 6 8 
A2CP/M 


4 


MS DOS 


MS DOS 


2 

5 
21 
22 


Apple DOS 3.3 
Apple SOS 
Apple ProDOS 
Macintosh 


A2DOS3.3 
A3S0S 
PRODOS 
MAC 


8 
9 


RT-11 
RSX-11 


RTll 
RSXll 


10 


Pet 


? 


11 
12 


NEWDOS 
NEWDOS-80 


NEWDOS 
NEW80 


13 


Atari DOS 2.0 


ATARI 


14 
23 


UNIX System 3 
UNIX System 5 


UNIX3 
UNIX5 



Constellation Software GTI 



A-4 



Appendix A 





Table 


A. 4 




Boot Types 


boot number 


computer type 


boot file name 


0, 1, 2, 3 


Apple II 


B00T.APPT,E2 


4, 5, 6, 7 


Concept 


BOOT. CONCEPT 


9 


IBM 


BOOT.IBMPC 


10 


Xerox 820 


BOOT.XR820 


11 


Zenith H89 


BOOT. HZ 8 9 


12 


NEC PC8000 


BOOT . NC 


13 


Pet 


BOOT. PET 


14 


Atari 800 


BOOT.ATARI800 


15 


TRS-8 MOD I 


BOOT.TRSI 


16 


TRS-80 MOD III 


BOOT.TRSIII 


17 


LSI-11 


B00T.T.SI11 


18 


Printer server 


BOOT.PRINTSRV 


19 


Apple /// 


BOOT. APPLE 3 


20 


DEC Rainbow 


BOOT. RAINBOW 


21 


TI Pro 


BOOT. TI PRO 


22 


Z-100 


BOOT.ZIOO 


23 


Concept2 


B00T.C0NCEPT2 


24 


Companion 


BOOT. COMPANION 


25 


Macintosh 


BOOT. MAC 


26 


Sony SMC-7086 


BOOT. SONY 
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Appendix B: Operating system specifics 

Each section covers the implementation details of the specified 
operating system. This information includes the following 
topics; 

o Overview. 

o Volume format. 

o Driver calls. 

o Description of mount table. 

o Memory locations used. 

o Boot/logon process. 

o Utilities. 
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B.l Corvus Concept Operating System 

You should also consult the following manuals: 

Corvus Concept Operating System Reference Manual, Corvus P/N: 
7100-02825. Describes how to write drivers; 
includes listing of system common. 

Corvus Concept System Library User Guide, Corvus P/N: 

7100-03295. Describes units CCDIRIO (directory 
i/o) , CCOMNIO and CCOTCIO (transporter interfaces) , 
CCDRVIO (Corvus drive interface) . 

Overview 

There are 4 disk drivers for the Concept Operating System: two 
floppy disk drivers and 2 hard disk drivers. The floppy disk 
drivers (DRV.FDISK and DRV.ADISK) are loadable; the hard disk 
drivers (Local and Omninet) are built into the CCOS kernel. 
Drivers are associated with unit numbers ranging from 1 to 36. 
By convention, disk drivers are only associated with units 4, 5, 
and 9 through 29. Unit 4 is always the system boot volume, and 
must contain certain operating system files. 

In addition to the disk drivers, there are two other drivers used 
by Constellation II. One is called SLOTIO and is used for 
sending arbitrary disk commands. The other is called OMNINET and 
is used for sending arbitrary Omninet commands. Bdth of these 
drivers are built into the CCOS kernel. 

Volume format 

The volume format used by CCOS is identical to that used for UCSD 
p-system volumes. By convention, volumes whose directory is 
stored with most significant byte first are called CCOS format, 
and volumes whose directory is stored with least significant byte 
first (a "flipped" directory) are called UCSD format. 

Refer to the Corvus Concept System Library User Guide, CCDIRIO 
unit, for more information. Constellation II software also uses 
the unit C2UTIL1 in library CIILIB.OBJ for directory i/o. 

The first two blocks of each volume are currently unused; these 
blocks are used for boot code on a floppy. The next 
4 blocks are the directory. Each directory entry is 26 bytes; 
there is space for 78 entries in the 4 blocks (78*2 6=2028 bytes; 
the remaining 20 bytes are unused) . The first entry in the 
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directory always describes the volume itself, giving volume size 
and number of files. The rest of the entries describe the 
individual files. Only the first n+1 entries are valid, where n 
is the number of files indicated in the volume entry. Unused 
entries may appear valid, since previously used entries are not 
zeroed out. 
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CCOS Volume layout 



Block I Byte I | 

+ + + 

I Unused (boot blocks for floppy) | 
+- -+ 

1 I I 

+ + 

2 0-25 1 Directory entry for volume | 

+ + 

26-511 Directory entry for file 1 | 

+ + 

52-77 1 Directory entry for file 2 | 

+ + 

78-511] More directory entries for files | 

3 I I 

< < 

> > 

5 I I 

+ + 

6 I Data area | 

< < 

> > 

n-1 I I 

+ __+ 

n is the volume length, as specified by the user when the volume 
was created. 

When formatting a volume with the Constellation II VOLUME MANAGER 
program, the user can choose 1 of 3 options. These have the 
following effect: 

1) Initialize volume: Read blocks 2 through 5. Create 

directory entry for volume, truncating volume name 
to 7 characters, and indicating files. Fill 
remainder of block 2 with OOh. Write blocks 2 
through 5. Note that only block 2 is actually 
changed by this option. 

2) Write volume header: Read blocks 2 through 5. Put new 

volume name and volume length into volume entry. 
Write blocks 2 through 5. Note that only the 
volume name and volume length are actually changed 
by this option. 

3) Zero directory: Same as option (1) . 
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Directory entry for volume 

Byte 

+ + 

I Firstblock - first block number of (msb) * | 
+- volume (usually OOOOh) -+ 

1 I (Isb) I 

+ + 

2 I Nextblock - first block number of (msb) | 
+- data area (usually 0006h) -+ 

3 I (Isb) I 

+ + 

4 I Fkind (low order 4 bits) - kind of (msb) | 
+- file (OOOOh for a volume) -+ 

5 I (Isb) I 

+ . + 

6 I Dtid[0] - length of volume name | 

+ + 

7 I Dtid - volume name (7 bytes max) | 
< < 
> > 

13 I I 

+ + 

14 I Deovblock - volume size (msb) | 

+- _+ 

15 I (Isb) I 

+ + 

16 I Dnumfiles - number of files in (msb) | 
+- volume -+ 

17 I (Isb) I 

+ + 

18 I Dloadtime - date of last access (msb) | 

+- _+ 

19 I (Isb) I 

+ + 

20 I Dlastboot - date of last boot (msb) | 

+_ _+ 

21 I (Isb) I 

+ + 

22 I Memflipped (see below) (msb) | 
+- -+ 

23 I Dskflipped (Isb) | 

+ + 

24 I Unused | 

+- -+ 

25 I I 

+ + 

* All entries marked with (msb) and (Isb) are flipped for UCSD 
format volumes. 
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Hemflipped and Dskflipped are only valid when the directory has 
been read into memory by the GetDir routine. 

The following test determines whether a directory is flipped or 
not: 

IF Nextblock = 3 OR Nextblock = 6 OR Nextblock = 10 THEN 
directory is not flipped 
ELSE 

IF Flip (Nextblock) = 3 OR Flip (Nextblock) = 6 OR 
Flip (Nextblock) = 10 THEN 
directory is flipped 
ELSE 

invalid directory. 

Values for FKind are given below: 

Fkind Meaning 






Volume 


2 


Code file 


3 


Text file 


5 


Data file 


8 


Volume 



The date field has the following format: 

Bits 0..6 (7 bits): year (0->1900, 84->1984) 

Bits 7.. 11 (5 bits): day 

Bits 12.. 15 (4 bits): month (l->Jan, 12->Dec) 



Constellation Software GTI B-6 



Concept OS 

Directory entry for file 

+ _ + 

I Firstblock - first block number of (msb) | 
+- file -+ 

1 I (Isb) I 

+ „ + 

2 I Nextblock - first block following (msb) | 
+- file -+ 

3 I (Isb) I 

+ + 

4 I Fkind (low order 4 bits) - file (msb) | 
+- type — + 

5 I (Isb) I 

+ + 

6 I Dvid[0] - length of file name | 

+ + 

7 I Dvid - file name (15 bytes max) | 
< < 
> > 

21 I I 
+ „ + 

22 I Dlastbyte - number of bytes in last (msb) | 
+- block -+ 

23 I (Isb) I 

+ + 

24 I Daccess - last modification date (msb) | 
+- -+ 

25 I (Isb) I 

+ . + 
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Driver calls 

CCOS defines the following driver calls: 

UNITREAD (unit number, buffer, byte count, block number, 

mode ) 
UNITWRITE (unit number, buffer, byte count, block number, 

mode ) 
UNITSTATUS (unit number, buffer, function code) 
UNITBUSY (unit number) 
UNITCLEAR (unit number) 
UNITMOUNT 
UNITUNMOUNT 
UNITINSTALL 

Refer to the Pascal Reference Manual or the Operating System 
Reference Manual for explanation of the parameters. 

The disk driver implements the following driver calls: 

UNITREAD (unit number, buffer, byte count, block number, 

mode ) 
UNITWRITE (unit number, buffer, byte count, block number, 

mode ) 

The SLOTIO driver implements the following driver calls: 

UNITREAD (unit number, buffer, byte count, block number, 

mode ) 
UNITWRITE (unit number, buffer, byte count, block number, 

mode ) 

UNITWRITE is used to send a drive command, and UNITREAD is 
used to receive the results. 

The unit number of the SLOTIO driver can be obtained by 
calling the parameterless function OSSltDv. 

The parameter buffer contains the drive command on UNITWRITE, 
and the command result bytes on UNITREAD. 

The parameter byte count contains the length of the command 
on UNITWRITE; for UNITREAD, byte count is set to the maximum 
number of bytes expected on the call, and on return it will 
be set to the number of bytes actually received. 

The parameter block number is not used. 

The mode parameter is used to specify the slot and server 
number that the command is directed to; mode.lsb = slot number; 
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mode.msb = server number (transporter address) . 

The OMNINET driver implements the following driver calls: 

UNITSTATUS (unit number, buffer, function code) 

For a description of the OMNINET driver, refer to the 
documentation on the CCOTCIO unit. 

Description of Concept mount table 

The Concept mount table is called the system device table 
(sysdevtab) , and is pointed to by bytes 20-2 3 of the system 
global area. The first word of the system device table indicates 
how many entries there are; each entry is described by the table 
on the next page: 
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+ + 

I Comnds I 
+- -+ 

1 I I 

+ + 

2 I Driver - address of the driver for this | 

< device < 

> > 

5 I I 

+ + 

6 I Blocked - TRUE for a disk device | 

+ + 

7 I Mounted - TRUE if a volume is currently | 
I mounted j 

+ + 

8 I Devname[0] - length of device name | 
+ + 

9 I Devname - device name (7 chars, max) | 

< < 

> > 

15 I I 

+ + 

16 I Devsize - volume length | 

< < 

> > 

19 I I 

+ + 

2 I Devslt - device slot number | 
+ — — — — — + 

21 I Devsrv - device server number (trans, add.) I 

+ + 

22 I Devdrv - disk drive number (1-4) | 

+ + 

23 I Devtyp - disk drive type | 
+ + 

24 I Devspt - sectors per track | 
+ + 

25 I Devtps - tracks per side | 
+ + 

26 I Devro - TRUE is volume is read-only | 
+ + 

27 I Devflp - TRUE if directory is flipped | 
+ + 

28 I Devblk - starting block address of volume | 

< < 

> > 
31 I I 
+ + 
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The following fields must be set when mounting a hard disk 
volume : 

Comnds - 15 

Driver - set to driver address, obtained from system slot 

table (SysSltTab.drv[Devslt]) 
Blocked - TRUE 
Mounted - TRUE 

Devname - first 7 characters of volume name 
Devsize - volume size 
Devslt - slot number of volume 
Devsrv - server number (transporter address) 
Devdrv - Corvus drive number 

Devro - TRUE for read-only; FALSE for read-write 
Devblk - starting block address of volume 

Memory locations used 

The pointer to the System Common area is located in bytes 18 Oh 
through 18 3h. 

The system device table pointer is located in bytes 2 Oh through 
23h of the System Common area. 

The encrypted user name is located in bytes 726h through 72Fh. 
The unencrypted user name is located in bytes 71Ch through 725h. 

Boot process 

After finding the user's boot volume, the boot code looks for the 
file CC. KERNEL in the boot volume. This file is loaded and 
control is passed to it, along with the following information: 

User name (encrypted and unencrypted) 

Boot volume information: unit number, slot number, server 
number, drive number and starting block address. 

When the screen goes blank after entering the user password, the 
boot code has completed executing. The lines of dots seen next 
on the screen are output during execution of CC. KERNEL. 

Once the kernel has completed, it transfers control to a program 
called CC. SETUP, which must also reside in the user's boot 
volume. This program blanks the screen, puts up the user 
windows, and builds the user's mount table. 

The mount table is built as follows: the access table is read 
from the current server, and each volume is either mounted on the 

Constellation Software GTI B-ll 



Concept OS 

specified unit, or, if a volume is already mounted on the 
specified unit, put into an "overflow" table. Additional access 
tables are read and volumes mounted from all other disk servers, 
starting with the lowest transporter address. After all access 
tables have been read, volumes from the "overflow" table are 
mounted on any available units. 

Utilities 

The following library units are described in the System Library 
User Guide: 

CCLIB 

CCDIRIO - directory description and I/O 
CCOMNIO - sending Omninet messages; obsolete 
CCOTCIO - new unit for Omninet interface; use it instead of 
CCOMNIIO 

C2LIB 

CCDRVIO - sending disk commands 
CCPIPES - sending pipes commands 
CCSEMA4 - sending semaphore commands 

The following library units are described in Chapter 6 of this 
manual : 

CIILIB 

C2UTIL1 - reading and writing volume directories, 

name and password encryption and decryption 
MOUNTS - mounting, unmounting disk volumes 

Utilities include a mount manager (CC.MNTMGR) , a spooler (SPOOL), 
and a despooler (DESPOOL) . 
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B.2 MSDOS l.X 



Drivers currently available: IBM PC/XT, TI Pro 

Overview 

DOS 1.x uses two files to boot from floppy: IBMBI0.COM and 
IBMD0S.COM. The file IBMBI0.COM contains the BIOS, while the 
file IBMD0S.COM contains the operating system. 

The BIOS provided by IBM for MSDOS 1.x is replaced by the BIOS 
supplied by Corvus. The Corvus-supplied BIOS duplicates that 
provided by IBM as well as providing a Corvus driver. The user 
must boot from the Corvus drive. 

A maximum of 10 Corvus volumes and 2 floppies may be mounted. 
Volumes are referred to externally by letters A through L; 
internally, volumes are referred to as unit numbers through 11. 
The volume mounted on unit A must contain the file C0MMAND.COM. 

The ability to dynamically mount and unmount volumes is severely 
limited in MSDOS 1.x. MSDOS uses a File Allocation Table (FAT) 
to control disk allocation; a copy of the FAT of each on-line 
volume is kept in memory. The memory space for the FAT is 
allocated at boot time, and cannot be changed. Therefore, 
whenever a volume is mounted, its FAT table must fit within the 
previous volume's FAT table. Corvus has extended this 
restriction to say that a volume mounted over another must match 
that volume's configuration exactly. 

Volume format 
See section B.3. 



Driver calls 

The driver calls for MSDOS 1.x are not docxamented. 

Description of mount table 

Several tables within the BIOS must be modified when mounting a 
volume. These are listed here merely as a summary; for complete 
information, consult the driver listings. 

MTTAB: Unit Assignment Table. One byte entry for each 

possible unit (0 to 11) , indicating whether unit is 
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unassigned, assigned to a floppy, or assigned to a 
Corvus volume. Also indicates read/write access 
for a Corvus volume. 

DVTDVR: Volume Configuration Pointer Table. One byte entry 
for each possible unit (0 to 11) . Each entry is a 
DPH entry number (see below) , so this table is 
really just a mapper of unit number to DPH entry 
number. 

OFBAS: Corvus drive (s) map. 5 byte entry for each possible 
Corvus volume. Index is masked from MTTAB entry. 
Each entry contains the starting disk block address 
of the volume and the Corvus server and drive 
number . 

DPH: Disk Configuration Tables. Each entry consists of a 
unit number followed by a pointer to a volume 
configuration. For any unit, at most one entry in 
this table is "activated" by an entry in the volume 
configuration pointer table DVTDVR. 

DPTx: Disk Parameter Table(s). 10 bytes each, one for each 
possible disk configuration. Pointed to by DPH. 
Includes information such as number of reserved 
sectors, FAT copies on disk number of directory 
entries, and sectors per disk. 



The figure below shows how the tables fit together: 
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Memory locations used 

Flat cable interface card: 
Disk i/o port #: 2EEh 

Disk status port #; 2EFh 
Drive ready: OOlh 
Bus direction: 002h 

Oitininet and flab cable interface card ROMs: 
Segment # of I/O ROM: DFOOh 
ROM entry points: DFOOh ; cold start 

DF03h ; warm start 
DF06h ; ROM I/O support routines 

Boot process 

MSDOS 1.x must be booted from the Corvus hard disk; that is, it 
is not possible to boot MSDOS 1.x from a floppy and then 
"log-on" to the Corvus. A boot from the Corvus hard disk is 
accomplished by jumping to the entry point of the Corvus 
supplied interface ROM at location DFOOh. The following BASIC 
program shows a jump to this ROM: 

10 DBF SEG=&HDFOO 
20 X = 
30 CALL X 
40 END 

The ROM code finds a disk server and loads the IBM boot code from 
the Corvus volume, using the Corvus Read Boot Block command. The 
boot code then prompts for the user name and password. It finds 
the user's home server and boot volume. 

The boot volume (the one marked with x in the Access Manager) 
must be a UCSD-format volume which contains the files 
IBM. MSDOS. BIO and IBM. MSDOS. DOS. The IBM. MSDOS . BIO file is 
supplied by Corvus on the distribution diskette C0RIBM3:. The 
IBM. MSDOS. DOS file is read from your IBM DOS boot diskette 
during installation. 

The boot code loads the files IBM. MSDOS. BIO and IBM. MSDOS. DOS and 
builds the user's mount table. Any units not assigned to a 
Corvus volume are assigned to the built-in floppy. Control is 
then transferred to DOS. 

All volumes mounted for the user must be MSDOS format volumes. 
The volume mounted on unit A must contain the IBM supplied file 
C0MMAND.COM. 
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Utilities 

A mount manager program (MNTMGR.EXE) provides the ability for a 
user to mount or unmount specific volumes. As mentioned above, 
this capability is limited in that volumes must be mounted over 
existing volumes, and the volume configurations of the two 
volumes must match exactly. 

A spooler (SPOOL.EXE) and despooler (DESPOOL.EXE) are also 
supplied. 

Each of these utilities is written in MS Pascal. 

An assembly language module provides the capability to send 
arbitrary commands to the Corvus drive. This module calls the 
driver to actually send the commands. The module DRIVEC2.0BJ is 
for use with the MS Pascal compiler; the module BDRIVEC2.0BJ is 
for use with the MS Basic compiler. 

The procedures supplied by the module are listed below: 

Pascal: Function INITIO: INTEGER 
Basic: CALL INITIO (A%) 

Must be called before any calls to other procedures in this 
module. This function ensures that the Corvus driver is 
installed, and returns a non-zero value if it is successful. 
If this function fails, it returns 0. 

Pascal: Procedure CDSEND( VAR st: LONGSTRING) 
Procedure CDRECV( VAR st: LONGSTRING) 
BASIC: CALL CDSEND(B$) 

These procedures are used to send (CDSEND) arbitrary 
commands to the Corvus drive, and receive (CDRECV) the 
results. The first two bytes of the parameter are treated 
as an integer specifying the number of bytes to send 
(CDSEND) , or the number of bytes received (CDRECV) . The 
remainder of the string contains the command bytes or result 
bytes . 

The ROM entry points are described next: 

To use the ROM, call the entry points with standard 8086 
intersegment CALL'S (long CALL'S). All registers will be 
preserved (including the flag register) . When using the I/O 
services entry point, codes will be returned in the AX and CX 
registers. 
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DFOOOh - Coldstart. The coldstart entry initializes the 
interface card, locates a disk server (if the 
interface card is Omninet) , loads the Constellation 
II boot program and transfers control to it. 

DF003h - Warmstart. The warmstart entry point initializes 
the interface card. This should be done once by 
all drivers and routines that use the I/O services. 

DF006h - ROM i/o services. The i/o services entry point 

contains routines to communicate with the Corvus 
disk drives and network servers. 

The request code and parameters for I/O services are passed in 
8086 registers as shown below: 

(AH) « Identify interface 

On exit 

(AL) = if Omninet interface card 
1 if flatCable interface 

with Omninet interfaces 

(AH) - Omninet transporter address 

If (AH) - 255 then another transporter 
with the same address is on the network. 

(AH) = 1 Xmit/Recv data to drive 

DS:(SI) address of data to send to drive 
ES:(DI) address of buffer for data from drive 
(CX) number of bytes of data to send to drive 

(max = 530) 
(DX) number of bytes wanted back from drive 

(do not include return code; max=530) 

with Omninet interfaces 

(AL) network address of disk server 

(BL) number of timer units to wait for reply 

from disk server; = do not abort, wait 

forever; timer unit is approx .86 seconds 
(BH) number of xmit trys; 255 - retry until 

success; should be greater than 0; 

= 255 trys. 

with flatCable interfaces 
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(BL) number of timer units to wait for disk 

drive to come ready before first byte is 
sent to drive; this is also the number 
of timer units to wait for the interface 
to turn around after the command sequence 
is sent to the drive; = do not abort, 
wait forever; timer unit is approx .86 
seconds 

On exit 

(AL) return code from drive. 255 = aborted 
(CX) number of bytes received from drive; 
count includes the return code. 

(AH) =2 Xmit data to network server 

ES:(SI) address of data to transmit to server 

(CX) number of bytes to transmit 

(AL) network address of server. Use 255 to 

broadcast to all servers. 
(BH) number of times to try to xmit. If this is 

a broadcast, number of times to xmit data. 

On exit 

(AL) = all ok 

255 = transmission aborted 

(AH) = 3 Xmit/Recv data to network server 

DS: (SI) address of data to transmit to server 
ES: (DI) address of buffer for data from server 
(CX) number of bytes to transmit (53 max) 
(DX) number of bytes to receive (53 max) 
(AL) network address of server. Use 255 to 

broadcast to all servers. 
(BL) number of timer units to wait for reply 

from server; = do not abort, wait 

forever; timer unit = approx .86 seconds 
(BH) number of times to try. Should be greater 

than 0; = 255 times. 

On exit 

(AL) - all ok 

255 B transmission aborted 

(AH) = 4 Find any disk server on network. Uses simple 

broadcast command, since any version disk server 
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recognizes this command. Requests 2 and 3 

require a disk server with multiple server support, 

(BL) number of timer units to wait for reply 
from server; = do not abort, wait 
forever; timer unit = approx .86 seconds 

(BH) number of times to try. Should be greater 
than 0; = 255 times. 

On exit 

(AL) = all ok 

255 s transmission aborted 

(AH) network address of disk server that 
responded 

(AH) = 5 Send write command to drive 

DS: (SI) address of command to send to drive 

ES: (DI) address of data to send to drive 

(CX) number of bytes of command to send to 

drive (normally 4) 
(DX) number of bytes of data to send to drive 

(normally 512.) 

with Omninet interfaces 

(AL) network address of disk server 

(BL) number of timer units to wait for reply 

from disk server; = do not abort, wait 

forever; timer unit is approx .86 seconds 
(BH) number of xmit trys. 255 = retry until 

success; should be greater than 0; 

= 255 trys. 

with flatCable interfaces 

(BL) number of timer units to wait for disk 

drive to come ready before first byte is 
sent to drive. This is also the number 
of timer units to wait for the interface 
to turn around after the command sequence 
is sent to the drive; = do not abort, 
wait forever; timer unit is approx .86 
seconds 



On exit 
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(AL) return code from drive. 255 = aborted 
(CX) number of bytes received from drive; 
count includes the return code 
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B.3 MSDOS 2.x, 3.x 



Drivers currently available: IBM PC/XT, TI Pro, DEC Rainbow 

You should also consult the following manuals supplied by your 
computer manufacturer: 

For IBM- PC, DOS 2.0 
DOS Manual 

For IBM-PC, DOS 3.0 

DOS 3.0 Technical Reference Manual, IBM P/N 6322677 

For TI Pro, 

For DEC Rainbow, 

General 

MSDOS Technical Reference Manual, Microsoft P/N 

Overview 

Versions 2 and 3 of MSDOS support attachable device drivers. The 
user boots from either the floppy disk or the fixed disk, and the 
Corvus-supplied driver file is loaded into the operating system. 
Note that booting from the Corvus drive is NOT supported for 
MSDOS 2.x and 3.x. 



Volume format 

MSDOS volumes on the Corvus consist of a 4 block Corvus volume 
header, followed by a normal MSDOS volume as described in 
your MSDOS documentation. Volume attributes are specified by 
the system manager when the volume is created; these include 
volume size, number of reserved sectors, cluster size, and number 
of directory entries. The other attributes of a volume are 
either fixed, or computed as shown below. 

Important note: If the number of reserved sectors is 1 or more, 
then a BIOS parameter block is written into the first reseirved 
sector, as described in the DOS documentation. Many 
applications use this BIOS parameter block, so you should always 
specify at least one reserved sector when creating a volume. 
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MS DOS Volume layout 

Block I Byte I I 

+ + + 

Corvus volume header (4 blocks) 

+ + . + 

I UCSD-style directory I 

< < 

> > 

2 I I 

+ + 

3 0-13 I Corvus parameter block I 

+ + + 

MSDOS volume (volume size minus 4) 

+ + + 

4 I X reserved sectors (default x=l) | 

+ + 

4+x (5) I 2 copies of FAT (2y sectors; default y=l) | 

+ + 

4+x+2y (7) I Directory (d sectors; default d=16) | 

+ + 

4+x+2y+d (23) I data area I 

< < 

> > 

n-1 (1023) I I 
+ + 

The block offsets for a volume created with the default 
parameters are given in parentheses. 

n is the volume size, specified by the user. 

There are 3 options a user can choose from when formatting a 
volume with the Corvus VOLUME MANAGER utility: 

1) Initialize volume: Write volume header (blocks 2 and 3) 

BIOS parameter block, FATs, and directory. 

2) Write header: Writes only blocks 2 and 3, and BIOS 

parameter block. 

3) Zero directory (volume must have a valid header): 

Writes FATs and directory. 
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Corvus Volume Header 
UCSD style directory blocks (blocks 0, 1, and 2) 

Blocks and 1 are unused. Block 2 is written with the following 
information: 

+ . + 

0,1 I First block number of volume OOOOh | 

+ . + 

2,3 I First block number of data 03 00h | 

+ + 

4,5 I File kind OOOOh | 

+ + 

6 I Length of volume name - user specified xxh| 

+ , . + 

7 I Volume name (7 bytes max) I 

< (first 7 bytes of user-specified volume < 

> name) > 

13 I 1 

+ . _ + 

14,15 I Volume size - user specified xxxxh | 

+ + 

16,17 I Number of files in volume OlOOh | 
+ + 

18,19 I Time of last access OOOOh | 

+ + 

20,21 I Date of last boot xxxxh | 

+ . + 

22,23 I Unused OOOOh I 

— + _. + 

24,25 1 Unused OOOOh I 

— + . + 

26,27 I First block number of file 0300h | 

+ + 

28,29 I Next block - volume size xxxxh | 

+ , . + 

30,31 I File kind - data file 0500h | 

+ + 

32 I Length of file name - 10 OAh | 

+ + 

33 I File name (15 bytes max) "MSDOS. DATA" | 

< < 

> > 

47 I I 

+ + 

48,49 I Bytes in last block - 512 0002h | 

+ + 

50,51 I Last modification date xxxxh | 

+ . + 



Constellation Software GTI 



B-23 



MSDOS 2.x 

The Corvus volume header is written on volume initialization, but 
is not used by any of the MSDOS utilities or drivers. 



Corvus parameter block 
The Corvus parameter block is block 3 of the volume. 

+ + 

I Bytes per sector - always 512 | 
+_ -+ 

1 I I 

+ + 

2 I Sectors per cluster - user specified | 
+_ _+ 

3 I I 

+ + 

4 I Number of reserved sectors - user i 
+_. _+ 

5 I specified | 

+ + 

6 I Number of FAT copies - always 2 | 

+- -+ 

7 I I 

+ + 

8 I Number of directory entries - user | 

+- -+ 

9 I specified | 

+ + 

10 I Sectors per volume - user specified | 
+_ _+ 

11 I I 

+ + 

12 I Sectors per FAT - computed | 

+- -+ 

13 I I 

+ + 

This data is written on volume initialization, and is used by the 
Corvus logon procedure and mount manager program when mounting a 
volume . 

Sectors per cluster may be one of the following values: 
1, 2, 4, 8, 16, 32, 64, 128. A volume may have a maximum of 4 086 
clusters, which means the maximum volume size is 523008 blocks 
(4086*128) . The default cluster size depends upon the volume 
size. The defaults are given in the table below: 
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Volume size: 0-1999 2000-15999 16000-31999 >=32000 
Default cluster 

size: 4 8 16 32 

Number of reserved sectors may be between and 32; default is l. 
If 1 or more reserved sectors are specified, a DOS BIOS parameter 
block is written into the first reserved sector (see description 
in following pages) . 

Number of directory entries may be between 16 and 4080; default 
is 256. Each directory entry occupies 32 bytes. Since the 
directory occupies an integral number of sectors, you should 
always specify the number of directory entries as a multiple of 
16 (16 entries * 32 bytes per entry = 512 bytes) . The first 
entry of the directory is initialized with a volume label, and 
the other entries are set to E5h (deleted file) . E5h is used 
rather than OOh to maintain compatibility with DOS 1.x. 

Sectors per volume is equal to the user specified volume length, 
minus 4. 

Sectors per FAT is computed from the number of clusters in the 
data area. The FAT contains 1.5 bytes for each cluster. Each 
FAT is initialized with the first 3 bytes set to F8h, FFh, FFh, 
and the remaining bytes set to OOh. 

DOS 3.x supports 2 kinds of FATs: 1.5 bytes per cluster, and 2 
bytes per cluster. Corvus only supports 1.5 bytes per cluster. 
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DOS BIOS parameter block 

The BIOS parameter block (BPB) is located in the first reserved 
sector. The format of the BPB is specified by DOS; this table 
shows, in parentheses, the values used by Corvus. CPB refers to 
the Corvus parameter block, described above. 

+ + 

I 3 byte near JUMP to boot code | 
+- -+ 

1 I (E9h, FDh, FFh — JMP 0) | 

2 I I 

+ + 

3 I 8 bytes OEM name and version | 
< < 
> ('•CORVUS20") > 

10 I I 

+ + 

11 I Bytes per sector - always 512 | 

12 I (same as CPB, bytes 0,1) | 

+ + 

13 I Sectors per allocation unit | 

I (same as CPB, bytes 2,3) | 

+ + 

14 I Number of reserved sectors | 
+- -+ 

15 I (same as CPB, bytes 4,5) | 

+ + 

16 I Number of FATs - always 2 | 
I (same as CPB, bytes 6,7) j 

+ + 

17 I Number of root directory entries | 

18 I (same as CPB, bytes 8,9) | 

+ . + 

19 I Number of sectors in logical image | 
+- -+ 

20 I (same as CPB, bytes 10,11) | 

+ + 

21 I Media descriptor - always FEh | 

+ + 

22 I Number of FAT sectors | 
+- -+ 

23 I (same as CPB, bytes 12,13) | 

+ + 

(continued on next page) 
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DOS BIOS parameter block 
(continued from previous page) 

+ + 

24 I Sectors per track - always | 
+- _+ 

25 I (OOOOh) I 

+ . + 

26 I Number of heads - always | 
+- -+ 

27 I (OOOOh) I 
+ . + 

28 I Number of hidden sectors - always | 

+- -+ 

29 I (OOOOh) I 
+ . + 



Driver calls 

Refer to the description of the MSDOS driver interface contained 
in your MSDOS documentation. 

The Corvus supplied driver file actually contains two drivers: a 
character device driver used for mounting volumes, and a blocked 
device driver, used for disk i/o. 

The blocked device driver supports up to 10 devices; the actual 
number of devices is determined at boot time, and is 2 greater 
than the number of mounted volumes. 

The character device driver is called "UTILHOOK". If you output 
a character to it, it returns a 4-byte address of the Corvus 
tables located within the driver. These tables can then be 
examined or modified. The Mount Manger program for MSDOS uses 
this feature to display and modify the user's mount information. 

Description of mount table 

Look at the Pascal source file CVUTILS.IMP for a description of 
the MSDOS mount tables. 

Memory locations used 
Not applicable. 
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Boot/loaon process 

Corvus does not support booting from the Corvus drive; the user 
must boot from some other device (e.g., a built-in floppy or 
fixed disk) , and have the Corvus driver configured in. Log-on is 
performed by the INIT function of the Corvus driver. 

Log-on prompts for the user name and password, locates the home 
disk server, and builds the user's mount table. 

Utilities 

See Section B.2 for information on utilities. In addition to the 
utilities described there, Corvus also supplies a spooler driver 
for MSDOS 2.x. 
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B.4 Softech p-system Version IV 

Drivers available for: IBM, DEC Rainbow, TI Pro, Z-100 

Internal Archictecture Manual, Chapter on Low-level I/O 
Program Development Reference Manual 
Adaptable System Installation Manual 

Overview 

There are many versions of the p-system available. The ones 
supported by Coirvus are listed below. 

Version IV. 3 from Softech supports external drivers. Corvus does 
not supply a driver for this version, although it is fairly 
straightforward for you to develop your own driver. 



IBM 



Corvus uses the 8086 p-system interpreter from Softech, 
and has modified the BIOS to support the Corvus drive. 
Corvus is currently supporting the version IV. 1 interpreter. 

Corvus also supplies a driver which links into the NCI 
C.x version of Softech 's version IV. 

Note that Corvus does NOT support the p-system supplied 
by IBM. 



TI 



Corvus uses a version IV interpreter supplied by NCI. 

Note that Corvus does NOT support the p-system supplied 
by TI. 

DEC Rainbow, Z-100 

Corvus uses the CP/M-86 adaptable p-system interpreter 
from Softech. All communication with the Corvus drive 
is handled with calls to the CP/M-86 BIOS, which contains 
a driver for the Corvus drive. 

Volume format 

The first two blocks of each volume are currently unused; these 

blocks are used for boot code on a floppy. The next 

4 blocks are the directory. Each directory entry is 26 bytes; 
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there is space for 78 entries in the 4 blocks (78*26=2028 bytes; 
the remaining 2 bytes are unused) . The first entry in the 
directory always describes the volume itself, giving volume size 
and number of files. The rest of the entries describe the 
individual files. Only the first n+l entries are valid, where n 
is the number of files indicated in the volume entry. Unused 
entries may appear valid, since previously used entries are not 
zeroed out. 



Constellation Software GTI B-3 



p-system IV. x 

p-system volume layout 

Block I Byte I I 
+ + ^ 

I Unused (boot blocks for floppy) | 

1 I 'I 
+ + 

2 0-25 1 Directory entry for volume | 

___+ . + 

26-511 Directory entry for file 1 | 
+ ^ 

52-77 1 Directory entry for file 2 | 
+ . ^ 

78-5111 More directory entries for files | 

+- _+ 

3 I I 

< < 

> > 

5 I I 
+ + 

6 I Data area | 

< < 

> > 
n-1 I I 

+ . + 

n is the volume length, as specified by the user when the volume 
was created. 

When formatting a volume with the Constellation II VOLUME MANAGER 
program, the user can choose 1 of 3 options. These have the 
following effect: 

1) Initialize volume: Read blocks 2 through 5. Create 

directory entry for volume, truncating volume name 
to 7 characters, and indicating files. Fill 
remainder of block 2 with OOh. Write blocks 2 
through 5. Note that only block 2 is actually 
changed by this option. 

2) Write volume header: Read blocks 2 through 5. Put new 

volume name and volume length into volume entry. 
Write blocks 2 through 5. Note that only the 
volume name and volume length are actually changed 
by this option. 

3) Zero directory: Same as option (1) . 
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Directory entry for volume 

Byte 
+ + 

I Firstblock - first block number of (lsb)*| 
+- volume (usually OOOOh) -+ 

1 I (msb) I 

+ + 

2 I Nextblock - first block number of (Isb) | 
+- data area (usually 0006h) -+ 

3 I (rosb) I 
+ + 

4 I Fkind (low order 4 bits) - kind of (Isb) | 
+- file (OOOOh for a volume) -+ 

5 I (msb) I 
+ + 

6 1 Dtid[0] - length of volume name | 
+ + 

7 I Dtid - volume name (7 bytes max) | 

< < 

> > 

13 I I 

+ + 

14 I Deovblock - volume size (Isb) | 
+- -+ 

15 I (msb) I 
+ + 

16 I Dnumfiles - number of files in (Isb) | 
+- volume ~+ 

17 I (msb) I 
+ + 

18 I Dloadtime - date of last access (Isb) | 
+_ -+ 

19 I (Kisb) I 
+ + 

20 I Dlastboot - date of last boot (Isb) | 
+_ -+ 

21 I (insb) I 
+ + 

22 I Unused I 

< < 

> > 
25 I I 
+ + 

* All entries marked with (Isb) and (msb) may be flipped. 

The following test determines whether a directory is flipped or 
not: 
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IF Nextblock = 3 OR Nextblock = 6 OR Nextblock = 10 THEN 
directory is not flipped 
ELSE 

IF Flip (Nextblock) = 3 OR Flip (Nextblock) = 6 OR 
Flip (Nextblock) = 10 THEN 
directory is flipped 
ELSE 

invalid directory. 

Values for FKind are given below: 

Fkind Meaning 






Volume 


2 


Code file 


3 


Text file 


5 


Data file 


8 


Volume 



The date field has the following format: 

Bits 0..6 (7 bits): year (0->1900, 84->1984) 

Bits 7.. 11 (5 bits): day 

Bits 12.. 15 (4 bits): month (l->Jan, 12->Dec) 
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Directory entry for file 



+ + 

I Firstblock - first block number of (Isb) | 
+- file -+ 

1 I (msb) I 
+ + 

2 I Nextblock - first block following (Isb) | 
+- file -+ 

3 I (msb) I 

+ + 

4 I Fkind (low order 4 bits) - file (Isb) | 
+- type — + 

5 I (rosb) I 
+ + 

6 I Dvid[0] - length of file name | 
+ + 

7 I Dvid - file name (15 bytes max) | 
< < 
> > 

21 I I 
+ + 

22 I Dlastbyte - number of bytes in last (Isb) | 
+- block -+ 

23 I (Isb) I 
+ + 

24 I Daccess - last modification date (msb) | 

+_ -+ 

25 I (Isb) I 
+ + 
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Driver calls 

The p-system defines the following driver calls: 

UNITREAD (unit number, buffer, byte count, block number, 

mode ) 
UNITWRITE (unit number, buffer, byte count, block number, 

mode ) 
UNITSTATUS (unit number, buffer, function code) 
UNITBUSY (unit number) 
UNITCLEAR (unit number) 

The parameters to these calls are documented in the p-system 
Program Development Reference Manual . 

Description of mount table 

p-system mount table 

+ . + 

I MntTab I 

< 8 bytes per entry < 

> 6 to 20 entries > 

I see next page for entry format | 

+ + 

n I UserNm - user name (encrypted) | 

< 10 bytes < 

> > 

I I 

+ + 

n+10 I Passwd - user password (encrypted) | 

< 8 bytes < 

> > 

I I 

+ + 

n+18 I HomeSrvr - home disk server address | 

+ + 

n+19 I CardType (O«0mninet, l=Flatcable) | 

+ * + 

n+20 I Workstation - user workstation address | 

+ + 
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Mount table entry 

+ + 

I WP (4 bits) I Drv (4 bits) (Isb) | 

+_ _+ 

1 I Srv - disk server number (insb) | 

+ + 

2 I Addr - block address of start of (msb) | 
+- volume -+ 

3 I I 

4 I I 

5 I (Isb) I 

+ + 

6 I MaxBlk - volume size (msb) | 
+- -+ 

7 I (Isb) I 

+ + 

Memory locations used 

Boot process 

For Softech p-system - 8086 interpreter 

The boot code is loaded from the Corvus volume. This code 
prompts for user name and password, locates the home disk server, 
loads the interpreter from the user's boot volume, builds the 
user's mount table, and transfers control to the interpreter. 
The interpreter expects to find the file SYSTEM. PASCAL in the 
volume mounted on unit 4. 

For NCI p-system 

The user boots from a floppy which has the Corvus driver 
configured into the file SYSTEM. IBM. Then the user executes the 
Corvus program LOGON. CODE, which prompts for the user name and 
password and builds the user's mount table. 



For Softech Adaptable p-system - CP/M 86 

The user boots into CP/M 86 from a floppy, 
executes the Corvus program . . . 



Then the user 
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Utilities 



Corvus supplies a mount manager (MNTMGR.CODE) , a spooler 
(SPOOL. CODE) , and a despooler (DESPOOL.CODE) . 

A logon program is also supplied. 

The following library units are supplied in the library 
CORVUS. LIB: 



Unit name 

UCDefn 

UCCrtIO 

UCOmnIO 

UCDrvIO 

UCSema4 

UCPipes 

Mounts 

CVCrypt 

C2Utill 



Description 



Miscellaneous declarations 

Console I/O 

Omninet message sending 

Corvus drive I/O, CDSEND, CDRECV 

Semaphore operations 

Pipes operations 

Mount procedures 

Encryption/decryption 

Miscellaneous procedures 
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B.5 CP/M 86 



Drivers currently available: DEC Rainbow, Z-100 

Overview 

The user boots into CP/M 86 normally (i.e., from a floppy or 
fixed disk) , and executes a Corvus supplied program, CLINKS 6x, 
which links itself into CP/M. This program intercepts all disk 
calls and handles the ones directed to volumes on the Cojtvus 
drive. A second program, LOGON. CRV, is used to build the user's 
default mount table. 

Volume format 

CP/M volumes on the Corvus consist of a 4 block Corvus volume 
header, followed by a normal CP/M volume as described in your 
CP/M documentation. Volume attributes are specified by the 
system manager when the volume is created; these include volume 
size, block allocation size, number of directory entries, number 
of sectors per track, and number of reserved tracks. The other 
attributes of a volume are either fixed, or computed as shown 
below. 
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CP/M Volume layout 

Block I Byte I | 
+ + . + 

Corvus volume header (4 blocks) 

+ + + 

I UCSD-style directory | 

< < 

> > 

2 I I 

+ . + 

3 0-50 I Corvus parameter block | 

+ + . + 

CP/M volume (volume size minus 4) 

+ + ^ 

I X reserved tracks (default x=0) | 
+ ■ + 

I Directory (d allocation units) | 

+ + 

I data area | 

< < 

> > 
n-1 (1023) I I 

+ . + 

Maximum volume size is 16388 blocks. 
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Corvus parameter block 
The Corvus parameter block is block 3 of the volume. 

+ + 

I CP/M volume header ID [1] I 

< (4 bytes of "CP/M") < 

> > 

3 I [4] I 
+ . + 

4 I CP/M volume information [1] | 

< (identifies system which created < 

> volume) > 

29 1 [26] I 
+ . + 

30 I Volume header revision level (Isb) | 

+- -+ 

31 I (msb) I 

+ + 

CP/M disk parameter block (DPB) 

+ . + 

32 I SPT - sectors per track (Isb) | 

+- -+ 

33 I (msb) I 
+ + 

34 I BSH - block shift factor | 

+ + 

35 I BLM - block mask I 

+ + 

36 I EXM - extent mask I 

+ + 

37 I DSM - total Storage capacity (Isb) | 
+- (in ELS units, minus 1) -+ 

38 I (msb) I 

+ + 

39 I DRM - total directory entries (Isb) | 
+- minus 1 -+ 

40 I (msb) I 

+ + 

41 I ALO - directory allocation flags | 
+ _ + 

42 I ALl - directory allocation flags | 

+ + 

(continued on next page) 
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Corvus parameter block 
(continued from previous page) 

+ + 

43 I CKS - directory check vector (Isb) | 
+- size -+ 

44 I (msb) I 

+ + 

45 I OFF - total reserved tracks (Isb) | 
+- -+ 

46 I (msb) i 

+ + 

end of CP/M DPB 

+ + 

47 I BLS - block allocation size (Isb) | 

48 I (msb) I 

+ + 

49 I TBK - total number of 512 byte (Isb) | 
+- blocks -+ 

50 I (msb) I 

+ + 



User specifes volume size, block allocation size (BLS) , 
number of directory entries (DRM) , sectors per track (SPT) , 
and number of reserved tracks. 

Maximum volume size is 16388 blocks. 

Block allocation size (BLS) specifies the size of each 
allocation unit, and is in units of 1024 bytes. Valid values 
are Ik, 2k, 4k, 8k, or 16k. The default value depends on volume 
size: 



Volume size (in blocks) : <2000 
Default BLS: 2k 



2000-7999 >=800C 
4k 8k 



In specifying number of directory entries, you should remember 
that each directory entry occupies 32 bytes. Also, the directory 
is allocated in BLS units; Ik will hold 32 directory entries. 
E.g., if your BLS is 8k, the number of directory entries should 
be a multiple of 256 (8*32) . 

The value specified for sectors per track (SPT) is only used to 
determine the amount of space to be reserved for number of 
reserved tracks (OFF) . Normally, SPT is 64 and OFF is 0. SPT 
must be a multiple of 4. 
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The values stored in the Corvus parameter block are determined as 
shown below: 

SPT (sectors per track) - user specified. 

BSH, BLM - computed from BLS, as shown: 

ELS BSH BLM 

2 4 15 

4 5 31 

8 6 63 

16 7 127 

EXM - computed from BLS and DSM, as shown: 

EXM 
BLS DSM<256 DSM>=256 



2k 10 

4k 3 1 

8k 7 3 

16k 15 7 

DSM - computed from volume size and BLS, as shown: 

DSM+1 = (volume size - 4 - 0FF*SPT/4) * 512 / BLS 
(rounded down to the nearest whole number) 

DRM - user specified 

ALO, ALl - computed from DRM and BLS. 

CKS - always 0, which disables checksumming of directory. 

OFF - user specified 

BLS - user specified 

TBK - computed from volume size, as shown: 
TBK = (DSM+1) *BLS/2 + 0FF*SPT/4 
Driver calls 
« to be supplied » 
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Description of mount table 
« to be supplied » 

Memory locations used 
« to be supplied >> 

Boot process 

The user boots from the floppy, and installs the Corvus driver by 
running the program CLINKS 6T ( CLINKS 6F for flat cable systems) . 
The user then logs on by running the program LOGON. 

Utilities 

Utilities include a mount manager (MNTMGR.CMD), a spooler 
(SPOOL.CMD), and a despooler (DESPOOL.CMD). 

An example program showing how to use semaphores is also provided 
( SEMA4 . CMD , SEMA4 . PAS ) . 

Since the driver does not support CDSEND and CDRECV, the assembly 
language module CPMI086.R86 is provided for this purpose. This 
module supports three functions: 

INITIO 

This function is provided for compatibility with MSDOS 
programs. It is a no-op for CP/M systems. 

SEND (var St: LONGSTRING) 
RECV (var st: LONGSTRING) 

The first two bytes of the parameter are the number of 
bytes to be sent or received. The remainder of the 
bytes of the parameter are the data to be sent or the 
data that was received. 

The file SEMA4.PAS gives examples of how these routines are 
called from Pascal MTS6+. 
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B.6 Apple II DOS 3.3 

Documentation : 

The Apple II DOS manual 

Beneath Apple DOS, by Don Worth and Pieter Lechner 

Overview 

Reference to the Corvus drive is accomplished by a logical 
mapping of the slot, drive, and volume specifiers of DOS to a 
volume on the Corvus. One Corvus super volume may be associated 
with each slot-drive combination; the vol\ime specifier of DOS is 
then mapped to a DOS volume located within the Corvus super 
volume. 

The user must boot from the Corvus drive. A DOS image is loaded 
from a reserved area of the Corvus drive, and is modified to use 
the Corvus driver which resides in RAM on the Corvus interface 
card. 

Volume format 

Constellation II uses a "super volume" to hold one or more DOS 
volumes. A user who has access to a super volume has access to 
each DOS volume within the super volume. DOS volumes within the 
super volume are numbered starting from 1. 

The 4 block Corvus volume header is initialized, but not used by 
any applications. 
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Apple DOS 3.3 Volume layout 

Block I Byte I | 

.+ + . + 

Corvus volume header (4 blocks) 

+ + + 

I UCSD-style directory | 

< < 

> > 

2 I I 

+ . + 

3 0-31 I Corvus parameter block | 

.+ + + 

DOS 3.3 volume (volume size minus 4) 

,+ + ^ 

4 I First DOS volume i 

< (280 blocks) < 

> > 

283 I I 

+ + 

284 I Second DOS volume | 

< (280 blocks) < 

> > 

563 I I 
+ + 

564 I Additional DOS volumes | 

< (280 blocks each) < 

> > 
n-1 (1023) I I 

Each DOS volume has the format described in the DOS manual. 

Directory starts at relative block 136 (track 17, sector 0) of 
each volume. Blocks 13 6 through 143 are written for directory 
initialization. 
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Corvus Volume Header 
UCSD style directory blocks (blocks 0, 1, and 2) 

Blocks and 1 are unused. Block 2 is written with the following 
information: 

+ _ + 

0,1 I First block number of volume OOOOh | 

+ + 

2,3 I First block number of data 03 00h | 

+ + 

4,5 I File kind OOOOh | 

+ + 

6 I Length of volume name - user specified xxh| 
+ + 

7 I Volume name (7 bytes max) I 

< (first 7 bytes of user-specified volume < 

> name) > 

13 I I 
+ + 

14,15 I Volume size - user specified xxxxh | 

+ + 

16,17 I Number of files in volume OlOOh | 

+ + 

18,19 I Time of last access OOOOh | 
+ + 

20,21 I Date of last boot xxxxh | 
+ + 

22,23 I Unused OOOOh | 

+ + 

24,25 I Unused OOOOh 1 

+ + 

26,27 I First block number of file 0300h | 
+ + 

28,29 I Next block - volume size xxxxh 1 
+ + 

30,31 I File kind - data file 0500h | 
+ + 

32 I Length of file name - 10 OAh | 
___+ ~ + 

33 I File name (15 bytes max) "DOS. VOLUME" | 

< < 

> > 

47 I I 
+ + 

48,49 I Bytes in last block - 512 0002h | 
__-+ + 

50,51 I Last modification date xxxxh | 
+ + 
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Corvus Volume Header 
Corvus parameter block (block 3) 



+ _ 

0-3 1 "DOS " 


+ 

1 


— +- 


-+ 


4-29 1 "Apple II DOS 3.3" 


1 


__ — 1-- 


-+ 


30-31 1 Revision level 


1 


_ — +_ 


-+ 


32-5111 Unused 

+ 


1 
+ 



The Corvus volume header is written on volume initialization, but 
is not used by any of the MSDOS utilities or drivers. 

Driver calls 

The Corvus driver resides in RAM on the Corvus interface card. 

The Corvus driver uses the RWTS interface defined by DOS. This 
interface is described in the Apple DOS manual. 

The first action taken by the Corvus driver is to examine the 
lOB. If the driver determines that the call is not for a Corvus 
device, then it returns control to DOS, which completes a normal 
RWTS call. If the call is for a Corvus device, then the driver 
executes the call, indicates the results by setting the field 
IBSTAT in the lOB, and returns control to the end of RWTS. 



Constellation Software GTI B-47 



Apple II DOS 3.3 



The following describes how the fields of the lOB are used 
by the Corvus driver: 

IBSLOT For Constellaion II, this value is checked against 
the entries in the slot/ drive array. If it 
matches one of those, the call is assumed to be 
for Corvus. 

IBDRVN Drive number (1 or 2) . For Constellation II, this 
value is used to find the proper entry in the 
slot/ drive array. 

IBVOL If IBVOL is 0, then it is replaced by the value 
conained in the last volume used location. If 
IBVOL is not 0, then the last volume used location 
is updated with IBVOL. 

IBTRK Corvus relative sector address « 
IBSECT 16*IBTRK + IBSECT 

IBBUFP Buffer address of where the data is read into or 
written from. 

IBCMD - command ignored; 2 - write; any other - read. 

IBSTAT Set to lOh if volume locked; if access denied; 
4 Oh for any other error. Carry is always set for 
any error, including access denied. Volume locked 
and access denied errors only occur with 
Constellation I and Single-user. 

IBSMOD 

The following fields of the lOB are not used: 

IBTYPE 
IBDCTP 
lOBPSN 
lOBPDN 



Description of mount table 

See next section. Memory locations used. 



Memory locations used 

The following memory locations are initialized on boot, and must 
be left unmodified. They hold information used by the Corvus 
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drivers. These locations are doctunented being used to hold DOS 
secondary boot code in "Beneath Apple DOS". This area is written 
to the boot tracks when a floppy is initialized. Hence, a floppy 
initialized when running Constellation II DOS is not bootable. 

B600h through B65C 

These bytes are used as follows: 

Location How used 



B600h RTS 

B601h-B603h JSR CxF4 ;where x=slot number — Corvus RWTS 

B604h-B606h JMP BD04 ;DOS RWTS 

B607h-B636h Mount table. See below for description. 

B637h-B640h User name (encrypted) . 

B641h Network transporter address. 

B642h Address of home disk server. 

B643h Home slot number. 

B644h Interface card bit map. See below for 

description. 
B645h-B64Ch Slot/drive array. See below for description. 
B64Bh-B650h Max volume array. See below for description. 
B651h-B656h Last volume used array. See below for 

description. 
B657h-B65Ch Reserved. 
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The mount table (bytes B607h-B636h) is 48 bytes long, and 
contains 6 entries of 8 bytes each. Each entry specified 
the network location of each super volume currently mounted, in 
the following format: 

byte Bit 7 (msb) is a write protect flag. If bit 7 is 
on, the volume is read-only; if bit 7 is off, the 
volume is read-write. 

Bits 6, 5, and 4 contain a slot number. This is 
the number of the slot containing the interface 
card connected to the server containing the 
volume . 

Bits 3, 2, 1, and contain a drive number. This 
is the number of the drive containing the volume. 

byte 1 Server number of the server containing the volume. 

bytes 2-5 A 4-byte absolute value (msb first) containing the 
starting block address of the volume. 

bytes 6-7 A 2-byte absolute value (Isb first) containing the 
length of the volume. 

The interface card bit nap (byte B644h) is used to indicate which 
Blots contain a Corvus interface card. Bits 6 through (msb 
first) map to slots 7 through 1. For example, bit 6 is on if 
there is a card in slot 1 , and bit 3 is on if there is a card in 
slot 4. 

The slot/drive array (bytes B645h-B64Ah) contains 6 bytes. Each 
byte indicates the slot/drive reference number for the 
corrensponding entry in the mount table. The upper 4 bits 
contain the slot number of the volume, and the lower 5 bits 
contain the drive number. For instance, if byte contains 41h, 
then slot 4, drive 1 refers to the first entry in the mount 
table. If byte 3 is 72h, then slot 7, drive 1 refers to entry 
number 3 in the mount table. 

The max volime array (bytes B64Bh-B650h) contains 6 bytes. It 
indicates the number of DOS volvunes in each super volume that is 
currently mounted. For instance, if byte 3 of the slot/drive 
array contains 42h, and byte 3 of the max volume array contains 
10, then the following references are valid: S4,D2,V5; 
S4,D2,V10. The following reference is invalid: S4,D2,V20. 

The last volume used array (bytes B651h-B656h) also contains 6 
bytes. It indicates the last volume accessed on each slot/drive 
entry. For instance, if you reference S4,D1,V6, then the entry 
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that corresponds to 41h will be set to 6. The next time you 
reference S4,D1, the driver will automatically access volume 6. 

It is possible to make a wholesale replacement of the DOS image 
in memory after booting Constellation II. Care must be taken to 
patch the appropriate memory locations described below, and the 
values of the B600 variables must be preserved during I/O 
operations. For example, these values may be moved by the 
application and the locations used for other data during non I/O 
operations. Replacement of the DOS image may, however, disable 
operation of the Corvus Constellation II utilities MOUNT MANAGER, 
SPOOL, and DESPOOL. 

The Corvus boot code patches DOS so that all RWTS calls are sent 
to the Corvus driver. This patch is described below. 

Location 3DBh contains the high order byte of the start of the 
RWTS subroutine. The Corvus patch is actually installed at a 
subroutine located 600h past the start of the RWTS subroutine. 
For instance, in standard DOS 3.3, location 3DBh contains the 
value B7h, and the Corvus patch is installed at location 
B700h+600h or BDOOh. For Constellation I, the patch consists of 
overwriting location BDOOh through BD02h with a JMP instruction 
to the Corvus interface card. For Constellation II, the 
destination of the JMP instruction is memory location B601. 

Boot process 

After booting. Constellation II looks for a HELLO program first 
on drive 1 of the highest logical slot mounted, and then on drive 
2 of this slot. If a HELLO program is found, it is loaded and 
run; otherwise the Applesoft prompt is displayed. 

Utilities 

« to be supplied » 
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